Re: Ravenscar-compliant bounded buffer

[Niklas Holsti <niklas.holsti@nospam.please>]

anon wrote:
> WHERE IS YOU PROOF!!! If your going to call a person a liar then you 
> should provide proof it.

Your quoting style (top-posting) makes me unsure what you are 
shouting about, but I assume it is my reply to your claim that GNAT 
  translates Ada to C. I see that others have already replied to 
your post, but as you call on me for proof I, too, answer.

Firstly, according to Pascal Obry you did not make such a claim in 
the post to which I replied. If so, I withdraw my reply, apologise 
for my misunderstanding of what you wrote, and have nothing more to 
say on that point (because then I don't understand *what* you were 
saying).

Secondly I did not call you a liar, I said your statement was 
nonsense. If you believe your own nonsense it does not make you a liar.

> Read NYU GNAT (before Adacore) internal messages regarding 
> GNAT-RTS and GNU C compiling system. It is a direct internal C tree 
> structure of the C code.

I gather from this that I did correctly understand that you claim 
that GNAT translates Ada to C. OK, I'll try to prove why that is 
not so. As the reference consider the paper "Integrating GNAT into 
GCC" by Richard Kenner, NYU, which was published in the Proceedings 
of Tri-Ada '94, Baltimore, Maryland, 1994 and is available in the 
ACM digital library (for subscribers).

This paper very clearly describes the GNAT compilation process: 
from source to an Ada Abstract Syntax Tree (AST), then expansion of 
the AST to bring it closer to the GCC concepts (replacing some 
high-level Ada constructs with lower-level expansions), then Gigi 
that generates a GCC tree from the Ada AST, followed by the general 
GCC back-end.

The main point to note is the term *GCC tree*, not *C tree*. 
Possibly the shorter term has been used elsewhere, but not in 
Kenner's paper.

Since your posts describe the same compilation steps your claim 
reduces to the question: is the GCC tree a form of C?

I'm sure that the concepts and structure of the GCC tree are closer 
to C than to Ada. That's natural because GCC originated as a C 
compiler. But Kenner describes important differences between the 
GCC tree and plain C.

At the start of section 4 (page 86) Kenner says "The GCC tree is 
already more general than required for C, so relatively few 
additions to the type model had to be made to support Ada." Thus 
the GCC tree can express concepts that have no direct C equivalent. 
Two examples that Kenner brings up are integer types with dynamic 
ranges, and arrays with non-zero lower index bounds.

In section 4.2 (page 86) Kenner explains that two new GCC node 
types were added to represent records with discriminants, and a new 
sort of GCC type was added to represent variant records.

Moreover, some capabilities of the GCC tree that GNAT uses come 
from the GNU extensions to C, not from standard C (before C99, at 
least): nested procedures and dynamically sized arrays on the stack 
(automatic arrays).

> That can be printed as a C program.

I'm not surprised that the GCC tree can be printed out as something 
that looks like C -- most program representations can. If the tree 
is the result of compiling a C program it might even be real, 
standard C. But I doubt if this "C printout" is real C for a GCC 
tree that comes from an Ada program, because of the features in the 
GCC tree that go beyond standard C.

> The XGC Ada which is based on GNAT and uses C for its Real Time 
> application and TLD contains C close sources files from DEC's Ada
> libraries, which denote that both do not have an "Ada only 
> Run-Time System". 

Prove it, eh :-)

>>Then there is the Open Ravenscar Kernel ORK for GNAT, 
> 
> The only problem with that one is that it is 4 years and gcc lib 
> are out dated.  The two I gave are current.

Good, the more the merrier. I believe the ORK work continues within 
or with the support of AdaCore, these days, but I may be mistaken 
on that.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .