Various Language Architecture Questions

Various Language Architecture Questions

[frankgerlach]

Hello,
I am contemplating to create a new language, which is supposed to be as
fast as C++, but as safe as Java.
Maybe Ada is already fulfilling these requirements, so I have a few
questions:
Is is possible to safely allocate objects on the stack and then pass a
pointer to these objects to a procedure ?
(The stack is very fast, but I cannot tolerate invalid references from
the heap or from "older" stack regions)
Are the common Ada runtimes performing range checks on Arrays,
including "casted" pointers ?
(Typecasting is necessary for high-performance access, but I want to be
safely in bounds of the array all the time)
Also, it should be forbidden (by compiler or runtime) to cast a type
that contains a pointer to a different type. Does Ada support this ? (I
must secure pointers in order to have only valid pointers in the
system. Invalid pointers introduce random errors or security problems
for a sandbox execution model)

Re: Various Language Architecture Questions

[jimmaureenrogers]

frankgerlach@gmail.com wrote:
> Hello,
> I am contemplating to create a new language, which is supposed to be as
> fast as C++, but as safe as Java.

Why limit yourself to a language as safe as Java?

> Maybe Ada is already fulfilling these requirements, so I have a few
> questions:
> Is is possible to safely allocate objects on the stack and then pass a
> pointer to these objects to a procedure ?

Within limits, yes.
The objects on the stack must be within scope when passed.

Ada has very strict scoping and lifetime rules.
You might want to read the Ada Reference Manual covering these
areas.
http://www.adaic.com/standards/95lrm/html/RM-TTL.html


> (The stack is very fast, but I cannot tolerate invalid references from
> the heap or from "older" stack regions)
> Are the common Ada runtimes performing range checks on Arrays,
> including "casted" pointers ?

Ada does not confuse arrays and pointers like C and C++.
Ada does perform range checks on arrays as a general rule.
There are some situations where the compiler can determine
that an out-of-range value is not possible, and therefore
eliminates the range check. The programmer is also free to
disable range checking when desired.

> (Typecasting is necessary for high-performance access, but I want to be
> safely in bounds of the array all the time)

Typecasting is not a way of life for Ada. It is somewhat unusual.
Ada access types (similar to references in Java) cannot be cast
from one type to another. Ada uses Unchecked_Conversion for that
purpose.

> Also, it should be forbidden (by compiler or runtime) to cast a type
> that contains a pointer to a different type. Does Ada support this ? (I
> must secure pointers in order to have only valid pointers in the
> system. Invalid pointers introduce random errors or security problems
> for a sandbox execution model)

Again, read the Ada language reference manual. Pay particular
attention to the Ada type model. You will find that Ada's concept
of type is far different than the C/C++/Java concept of a type.

Primitive types can be coerced from one to the other with limitations.
You cannot coerce a real number type to or from an integer number
type. You cannot coerce an enumeration type to or from an
integer number type.

You cannot coerce any compound type to another compound type or to
a scalar type.

Tagged types do allow you to operate with a limited view of an object
within the same inheritance hierarchy, but there is no true
coercion or casting.

Jim Rogers

Re: Various Language Architecture Questions

[Martin Dowie]

jimmaureenrogers@worldnet.att.net wrote:
> Typecasting is not a way of life for Ada. It is somewhat unusual.
> Ada access types (similar to references in Java) cannot be cast
> from one type to another. Ada uses Unchecked_Conversion for that
> purpose.

You would have to ensure that the underlying representation of each 
access type was the same - Ada does not require that all access types be 
a simple address. Alternatively, you could use 
System.Address_To_Access_Conversions.

But the main point is that in Ada you have to be explicit and it is easy 
to spot these 'dangerous' behaviors.


> You cannot coerce a real number type to or from an integer number
> type.

Are you sure about that Jim? :-)

declare
    I : Integer := 10;
    F : Float   := 1.0;
begin
    F := Float (I);
    I := Integer (F);
end;

Or did you mean something else by 'coerce'?

Cheers

-- Martin

Re: Various Language Architecture Questions

[Martin Krischik]

frankgerlach@gmail.com wrote:

> Hello,
> I am contemplating to create a new language, which is supposed to be as
> fast as C++, but as safe as Java.

Ada is not as save as Java - it's a lot saver.

As for speed: thats tricky. If you program as defensive in C++ as Ada is
from nature Ada will probably outperform C++. But most C++ programs are not
that defensive.

You might want to read:

http://en.wikibooks.org/wiki/Ada_Programming/Error_handling#Design_by_Contract

> Maybe Ada is already fulfilling these requirements, so I have a few
> questions:

The answer to all questions is indeed "Yes".

> Is is possible to safely allocate objects on the stack and then pass a
> pointer to these objects to a procedure ?
> (The stack is very fast, but I cannot tolerate invalid references from
> the heap or from "older" stack regions)

http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#The_class-wide_type

> Are the common Ada runtimes performing range checks on Arrays,
> including "casted" pointers ?
> (Typecasting is necessary for high-performance access, but I want to be
> safely in bounds of the array all the time)

Ada supports more then just "typecast" - it has more different "cast"
operators then modern C++ has:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes#Converting_data

> Also, it should be forbidden (by compiler or runtime) to cast a type
> that contains a pointer to a different type. Does Ada support this ? (I
> must secure pointers in order to have only valid pointers in the
> system. Invalid pointers introduce random errors or security problems
> for a sandbox execution model)

Ada's "pointer" management is a lot more complex. Read:

http://en.wikibooks.org/wiki/Ada_Programming/Memory

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Various Language Architecture Questions

[Dmitry A. Kazakov]

On 24 Sep 2005 19:37:12 -0700, frankgerlach@gmail.com wrote:

> Is is possible to safely allocate objects on the stack and then pass a
> pointer to these objects to a procedure ?

Why should you? Ideally in a high-level language there should be no
pointers but objects. The way objects are passed should be up to the
compiler.

> (The stack is very fast, but I cannot tolerate invalid references from
> the heap or from "older" stack regions)
> Are the common Ada runtimes performing range checks on Arrays,
> including "casted" pointers ?
> (Typecasting is necessary for high-performance access,

This is a wrong proposition. You don't need type casting to achieve the
best possible performance. Otherwise, a need in type casting just indicates
weakness of the type system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Various Language Architecture Questions

[frankgerlach]

Whatabout the following examples:
1.) Simple,unportabe Network Data Transport: To transport a C struct, I
just cast it to char* and then write sizeof(myStruct) bytes to the
Socket. This is very fast and works in a homogeneous network.
2.) Using Unchecked_conversion() in Ada kills range checking ? That
seems to be inferior to java...

Re: Various Language Architecture Questions

[Larry Kilgallen]

In article <1127652977.471484.203180@g47g2000cwa.googlegroups.com>, frankgerlach@gmail.com writes:

> 2.) Using Unchecked_conversion() in Ada kills range checking ? That
> seems to be inferior to java...

Using Unchecked_conversion in general is inferior to not using it,
but there are many capabilities in Ada to avoid the temptation to
use Unchecked_conversion.   You should revisit the exact reason why
you think Unchecked_conversion is necessary in your Ada program.

Re: Various Language Architecture Questions

[Pascal Obry]

frankgerlach@gmail.com a �crit :
> Whatabout the following examples:
> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
> just cast it to char* and then write sizeof(myStruct) bytes to the
> Socket. This is very fast and works in a homogeneous network.
> 2.) Using Unchecked_conversion() in Ada kills range checking ? That
> seems to be inferior to java...

Yes of course, then you'll now can start learning Ada :)

Check the 'Input 'Output attributes and the Stream support in Ada. Yes
you can even send an object over the network which is not possible in C++!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Various Language Architecture Questions

[Martin Krischik]

frankgerlach@gmail.com wrote:

> Whatabout the following examples:

> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
> just cast it to char* and then write sizeof(myStruct) bytes to the
> Socket. This is very fast and works in a homogeneous network.

You use 'Output and 'Write to achieve that in Ada:

http://en.wikibooks.org/wiki/Ada_Programming/Input_Output#Stream_I.2FO

You won't need a type convertion.

> 2.) Using Unchecked_conversion() in Ada kills range checking ? That
> seems to be inferior to java...

Then don't - there are lots of other conversions available in Ada.
Unchecked_conversion is for system programming not to gain speed.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Various Language Architecture Questions

[Georg Bauhaus]

frankgerlach@gmail.com wrote:
> Whatabout the following examples:
> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
> just cast it to char* and then write sizeof(myStruct) bytes to the
> Socket. This is very fast and works in a homogeneous network.

Pascal Obry has mentioned the 'Write attribute.
That is something you can supply for a record type,
together with a socket stream, for example.
 You could have the stream implementation just write
a number of storage_elements to the socket for a record
value.

> 2.) Using Unchecked_conversion() in Ada kills range checking ? That
> seems to be inferior to java...

Consider the name of the thing: Unchecked_Conversion. That is,
a non-checked re-interpretation of the bits. There are checked conversions,
too.

Re: Various Language Architecture Questions

[Georg Bauhaus]

Georg Bauhaus wrote:
> Pascal Obry has mentioned the 'Write attribute.
or so I thought. 'Output really, but they are related.

Re: Various Language Architecture Questions

[Pascal Obry]

Georg Bauhaus a écrit :
> Georg Bauhaus wrote:
> 
>> Pascal Obry has mentioned the 'Write attribute.
> 
> or so I thought. 'Output really, but they are related.

Ok ;-)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Various Language Architecture Questions

[Pascal Obry]

Georg,

> Pascal Obry has mentioned the 'Write attribute.

No I did mention 'Output. 'Output does stream the object tag, the bounds
of unbounded arrays... So the 'Input can build the proper object on the
other side :) 'Read/'Write are called respectively by 'Input/'Output to
stream the binary object representation.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Various Language Architecture Questions

[Maciej Sobczak]

frankgerlach@gmail.com wrote:

> Whatabout the following examples:
> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
> just cast it to char* and then write sizeof(myStruct) bytes to the
> Socket. This is very fast and works in a homogeneous network.

I guess that the time spent on the protocol stack and in all the network 
equipment is much bigger than what is needed to construct a correct 
packet, so being "fast" here is just a premature optimization.
Sending C structs by pointer+sizeof is asking for trouble, even if you 
accept it to be non-portable. I prefer careful packet composition.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Various Language Architecture Questions

[Florian Weimer]

* Maciej Sobczak:

> frankgerlach@gmail.com wrote:
>
>> Whatabout the following examples:
>> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
>> just cast it to char* and then write sizeof(myStruct) bytes to the
>> Socket. This is very fast and works in a homogeneous network.
>
> I guess that the time spent on the protocol stack and in all the network 
> equipment is much bigger than what is needed to construct a correct 
> packet,

Unfortunately, this is not true for some commonly used marshaling
schemes.  Even Ada.Streams can be relatively slow (with long arrays
with small components, for example).

Re: Various Language Architecture Questions

[Simon Wright]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Maciej Sobczak:

>> I guess that the time spent on the protocol stack and in all the network 
>> equipment is much bigger than what is needed to construct a correct 
>> packet,
>
> Unfortunately, this is not true for some commonly used marshaling
> schemes.  Even Ada.Streams can be relatively slow (with long arrays
> with small components, for example).

I've never understood why this _has_ to be. You would have thought
implementations could behave 'as if' to a large extent. If the stream
runs out of room or gets closed by peer I'm not sure that I care
exactly how many bytes got sent, do I?

Re: Various Language Architecture Questions

[Tapio Kelloniemi]

Simon Wright <simon@pushface.org> wrote:
>Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Maciej Sobczak:
>
>>> I guess that the time spent on the protocol stack and in all the network
>>> equipment is much bigger than what is needed to construct a correct
>>> packet,
>>
>> Unfortunately, this is not true for some commonly used marshaling
>> schemes.  Even Ada.Streams can be relatively slow (with long arrays
>> with small components, for example).
>
>I've never understood why this _has_ to be. You would have thought
>implementations could behave 'as if' to a large extent. If the stream
>runs out of room or gets closed by peer I'm not sure that I care
>exactly how many bytes got sent, do I?

In some circumstances you might want to know that, for example when
transferring critical data over unreliable network. Of course the protocol
must understand resuming. But still this does not mean that stream elements
must be written one by one (I suppose this is the problem why stream I/O
is slow). read(2), write(2) and scatter-gather I/O (POSIX) functions can
return the number of bytes transmitted even though they are fast.

-- 
Tapio

Re: Various Language Architecture Questions

[Florian Weimer]

* Simon Wright:

>> Unfortunately, this is not true for some commonly used marshaling
>> schemes.  Even Ada.Streams can be relatively slow (with long arrays
>> with small components, for example).
>
> I've never understood why this _has_ to be. You would have thought
> implementations could behave 'as if' to a large extent.

Not unless this is explicitly specified because the number of calls is
observable in most cases.

Re: Various Language Architecture Questions

[Simon Wright]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Simon Wright:
>
>>> Unfortunately, this is not true for some commonly used marshaling
>>> schemes.  Even Ada.Streams can be relatively slow (with long arrays
>>> with small components, for example).
>>
>> I've never understood why this _has_ to be. You would have thought
>> implementations could behave 'as if' to a large extent.
>
> Not unless this is explicitly specified because the number of calls is
> observable in most cases.

As would be the case if you had specified TCP_NODELAY, of course! (or,
worse, are using UDP).

We stream to an in-memory stream and then send the contents to the
socket in one chunk.

Re: Various Language Architecture Questions

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87oe6eoz40.fsf@mid.deneb.enyo.de...
> * Simon Wright:
>
> >> Unfortunately, this is not true for some commonly used marshaling
> >> schemes.  Even Ada.Streams can be relatively slow (with long arrays
> >> with small components, for example).
> >
> > I've never understood why this _has_ to be. You would have thought
> > implementations could behave 'as if' to a large extent.
>
> Not unless this is explicitly specified because the number of calls is
> observable in most cases.

Yes, but Ada 200Y gives this explicit permission (see 13.13.2(56/2)). That's
especially important since Ada 95 compilers tended to take the pessistic
view, which makes streaming a lot slower than it has to be. Note that that
permission is available in Ada 95 as well (AI-195 is a Binding
Interpretation; the thinking was that leaving that permission out was an
oversight in Ada 95, one of many in the streaming stuff).

                           Randy.

Re: Various Language Architecture Questions

[Florian Weimer]

> 1.) Simple,unportabe Network Data Transport: To transport a C struct, I
> just cast it to char* and then write sizeof(myStruct) bytes to the
> Socket. This is very fast and works in a homogeneous network.

The speed gain is usually not worth the portability loss.  If you have
to copy the data just once (as it is common with stream-oriented data
transmission), it's possible to get proper marshaling almost for free.
(There are template metaprogramming libraries which can do this for
C++.  For Ada, you'd need a little code generator.)

Re: Various Language Architecture Questions

[Marin David Condic]

frankgerlach@gmail.com wrote:
 > Hello,
 > I am contemplating to create a new language, which is supposed to be as
 > fast as C++, but as safe as Java.


Others seem to have answered your immediate questions, but I would add 
the observation that in Ada it is far far far less necessary to be 
creating pointers to everything as is typically done in C/C++, et alia. 
CLA often gets questions like that from C/C++ programmers because 
they're so used to the necessity of pointers in order to get 
pass-by-reference behavior & deal with other language-specific issues.

Also, in a well designed Ada program (one in which you have given some 
thought to the types you create) it is far less necessary to do 
"casting" or other tactics to get one data object to look like another. 
This might be done frequently in other languages to achieve what Ada 
gets through generics and other language features. If you find yourself 
doing a lot of type conversions or Unchecked_Conversion calls in Ada, 
then its likely you are not using the language features properly and may 
be simply trying to write C code in Ada.

If you're interested in Ada, take time to learn it reasonably thoroughly 
because you don't simply want to write C code in Ada syntax.

MDC



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: No.Mcondic.Spam@Del.Mindspring.Com
(Remove the "No.", ".Spam" and "Del." for the real address.)

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Various Language Architecture Questions

[Björn Persson]

frankgerlach@gmail.com wrote:
> I am contemplating to create a new language, which is supposed to be as
> fast as C++, but as safe as Java.

Then you should definitely learn Ada. Don't stop when you've got answers 
to the questions you have now. Learn Ada thoroughly! I also suggest that 
you look around for other languages with interesting features, 
especially if C++ and Java are the only languages you know.

Why? Because the more programming languages you know, the better you can 
see the strengths and weaknesses of each language. Even if you 
eventually decide that Ada isn't what you're looking for, you will most 
certainly learn things from Ada � and from other languages � that you 
can use when you design your own language, making your language better 
than it otherwise would have been.

And whatever you do, don't include the if(a=b) bug in any new language!

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Various Language Architecture Questions

[Jeffrey R. Carter]

frankgerlach@gmail.com wrote:

> I am contemplating to create a new language, which is supposed to be as
> fast as C++, but as safe as Java.

Your thinking is very low-level. With a well designed language, pointers and 
type conversions are far rarer than in C/++. When you have been exposed to such 
a language well enough to use it as intended, then you may be ready to think 
about designing a language of your own.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: Various Language Architecture Questions

[David Emery]

Part of the goal for any modern protocol stack should be type safety, including preventing array bounds overrunning.  For what it's worth, I wrote a significant subset of TCP using SPARK as part of a IR&D project in applying SPARK/formal methods.  With a little bit of care and attention, there should be little or no performance hit for A LOT of safety/security.  The parts I couldn't do in SPARK (such as asynchronous transfer of control to implement TCP timeouts) were done in Ada95.  The Ada95 was wrapped in C to support the JNI interface for the test/demonstration code that invoked the protocol stack.  We called the result (Java calling C calling Ada95 calling SPARK) the "SPARK Sandwich"...

The core concern is at boundries of the protocol layer, where you move from byte sequences to packets, and then to more 'semantically knowledgeable' data.  

		dave

Jeffrey R. Carter wrote:
> frankgerlach@gmail.com wrote:
> 
>> I am contemplating to create a new language, which is supposed to be as
>> fast as C++, but as safe as Java.
> 
> 
> Your thinking is very low-level. With a well designed language, pointers 
> and type conversions are far rarer than in C/++. When you have been 
> exposed to such a language well enough to use it as intended, then you 
> may be ready to think about designing a language of your own.
>