Teaching new tricks to an old dog (C++ -->Ada)

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang. ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

[Larry Kilgallen]

In article <11************ *@corp.supernew s.com>, CTips <ct***@bestweb. net> writes:

Peter Amey wrote:

They can, in any case be turned off if the user requires a different
performance/safety tradeoff.

Are you sure? Do I have to recompile the whole program in that case?

At a maximum, recompile the module that has become performance critical.

[Dmitry A. Kazakov]

On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

How easy is it to build an arena allocator in Ada?
It is trivial:

type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Stor age_Pool use My_Arena;

Here you are:

Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

Note that Object can still be allocated on the stack or in any other pool:

type Object_Universa l_Ptr is access all Object;

This : Object;
-- This allocates it on the stack
That : Object_Universa l_Ptr := new Object;
-- This will be in the(a) default pool (in the heap)
Given a processor with load-word-locked and store-word-conditional, how
would I build an atomic increment function?

Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;

-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;

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

[Martin Dowie]

Jerry Coffin wrote:

In fact,
any software system over a half-million lines of
source code should be coded in
Ada.

Here, however, you lose your grip on reality. This is NOT "in fact" --
it's purely an OPINION! It's certainly possible to find projects that
would involve more than a half-million lines of code for which Ada
would be _extremely_ poorly suited, at best.

It's an opinion /nearly/ shared with P. J. Plauger of the ANSI-C
committee (and Dinkumware) - only I believe he quoted 100 thousand lines
as the point at which you should be using Ada. :-)

Cheers

-- Martin

[CTips]

Pascal Obry wrote:

CTips <ct***@bestweb. net> writes:

Free? Well, lets look at one particular issue: pointers to arbitrary
locations. In C, its a common idiom to do the following:
foo(int * p)
{
int * z;
for( i ... ) {
... p[i]...;
}
z = p;
}

...
foo( &x[lo] );
...

Now, how can *any* language check to see that p[i] is within bounds?

Good you asked! Let's code this example in Ada (using Ada and
not C/C++ style, in Ada for the above example we do not need a pointer):

type T is array (Positive range <>) of Integer;

procedure Foo (P : in out T) is
Z : Positive;
begin
for I in P'Range loop
... P(i)...;
-- Here P(i) is always within the bounds, no check needed.
end loop;
Z := P'First;

Nope, not z = p[0], z = p; Z is a _pointer_ to int, not an int.
end Foo;

...

Foo (X (Lo .. X'Last));

Bullsh*t. In several ways, of which two are:

Given your assumption about maybe you just don't know Ada.

Try again. Show me how sizeof(z) != 8 in Ada.

Pascal.

[CTips]

Dmitry A. Kazakov wrote:

On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

How easy is it to build an arena allocator in Ada?

It is trivial:

type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Stor age_Pool use My_Arena;

Here you are:

Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

And how is My_Arena defined? Is it just a blob of memory? Or is it a
"class" that can invoke sbrk (or whatever) when it needs to?

Note that Object can still be allocated on the stack or in any other pool:

type Object_Universa l_Ptr is access all Object;

This : Object;
-- This allocates it on the stack
That : Object_Universa l_Ptr := new Object;
-- This will be in the(a) default pool (in the heap)

Given a processor with load-word-locked and store-word-conditional, how
would I build an atomic increment function?

Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;

-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;

Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.

[Larry Kilgallen]

In article <1i************ *************** ***@40tude.net> , "Dmitry A. Kazakov" <ma*****@dmit ry-kazakov.de> writes:

On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

Given a processor with load-word-locked and store-word-conditional, how
would I build an atomic increment function?

Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;

-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;

In other words, the code generator within the Ada compiler takes care
of the load-locked store-conditional aspects of the architecture.

What Dmitry has shown is how the programmer accesses that capability.

[Pascal Obry]

CTips <ct***@bestweb. net> writes:

Nope, not z = p[0], z = p; Z is a _pointer_ to int, not an int.
Look at your program. You do nothing with Z so my solution is equivalent.
That's the point.
Try again. Show me how sizeof(z) != 8 in Ada.

Sorry I don't parse this one. I don't care about the size of Z! I care about
what my application has to do. So if you tell us what you want to achieve we'll
provide the solution using Ada not Ada-Transtaled-From-C++ one. It is always a
mistake to copy the solution word for word when translating from one language
to another.

chauve-souris /= bald-mouse

Pascal.

--

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

[Georg Bauhaus]

CTips wrote:

Dmitry A. Kazakov wrote:

type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Stor age_Pool use My_Arena;

Here you are:

Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

And how is My_Arena defined? Is it just a blob of memory? Or is it a
"class" that can invoke sbrk (or whatever) when it needs to?

My_Arena is a storage pool, storage pool is a term
defined by the language.
Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.

For how many concurrently executing threads
of control, each invoking the incrementing function,
will this work? (Without any addition that is, as in
the Ada example)

Georg

[Dmitry A. Kazakov]

On Tue, 08 Mar 2005 15:13:20 -0500, CTips wrote:

Dmitry A. Kazakov wrote:

On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:

How easy is it to build an arena allocator in Ada?

It is trivial:

type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Stor age_Pool use My_Arena;

Here you are:

Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena

And how is My_Arena defined? Is it just a blob of memory? Or is it a
"class" that can invoke sbrk (or whatever) when it needs to?

It is completely up to you. My_Arena has to be derived from
System.Storage_ Pools.Root_Stor age_Pool. Which is the abstract base of all
storage pools. The implementation of Allocate and Deallocate is at your
discretion. For an arena the pool may contain a statically allocated array
organized as a stack. Deallocate could be then void, or it can pop
everything above it as in mark'n'release. A more advanced application could
allocate memory in segments at request etc. For a sample implementation of
a segmented stack pool see:

http://www.dmitry-kazakov.de/ada/com....htm#Pools_etc

Given a processor with load-word-locked and store-word-conditional, how
would I build an atomic increment function?

Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;

-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;

Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.

Ask your compiler vendor. Though it wouldn't be necessarily polling. Also
usually protected objects are not used for so utterly fine-grained mutual
exclusion/locking. Atomic integer increment is normally just a small part
of some larger (but not lengthy) operation. For example, placing something
in a queue. Therefore spinning for a lock (which probably would be the
implementation) will likely be less expensive than some tricky guards
attached to each and every instruction. Note also that at such a low level
it would be very difficult if possible to maintain data consistency.
Compiler simply does not know what is related to what and will try to cope
with the worst case scenario. Protected types in Ada are to describe this
sort of semantics. So in the end atomic integers are pretty useless, no
matter how efficient they could be implemented.

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

[Pascal Obry]

CTips <ct***@bestweb. net> writes:

protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;
-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;

Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.

No protected type implementations will be so light. This is impossible as it
brings far more than atomic integer. For an atomic integer it is possible to
declare :

Value : Integer;
pragma Atomic (Value);

In this case it would be nice to see the generated code.

Pascal.

--

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