Ravenscar-compliant bounded buffer

Ravenscar-compliant bounded buffer

[Maciej Sobczak]

In one of my previous posts I have criticized example 12 from the
Ravenscar document.
It makes sense to criticize constructively, I think. :-)

-- bounded_buffer.ads
package Bounded_Buffer is

   type Buffer_Type is limited private;

   procedure Put (Buffer : in out Buffer_Type; Item : in Integer);
   procedure Get (Buffer : in out Buffer_Type; Item : out Integer);

private

   protected type Binary_Semaphore (Initial_State : Boolean) is
      entry Acquire;
      procedure Release;
   private
      Available : Boolean := Initial_State;
   end Binary_Semaphore;

   type Buffer_Type is limited record
      Storage : Integer;
      Available_For_Reading : Binary_Semaphore (Initial_State =>
False);
      Available_For_Writing : Binary_Semaphore (Initial_State =>
True);
   end record;

end Bounded_Buffer;

-- bounded_buffer.adb
package body Bounded_Buffer is

   procedure Put (Buffer : in out Buffer_Type; Item : in Integer) is
   begin
      Buffer.Available_For_Writing.Acquire;
      Buffer.Storage := Item;
      Buffer.Available_For_Reading.Release;
   end Put;

   procedure Get (Buffer : in out Buffer_Type; Item : out Integer) is
   begin
      Buffer.Available_For_Reading.Acquire;
      Item := Buffer.Storage;
      Buffer.Available_For_Writing.Release;
   end Get;

   protected body Binary_Semaphore is

      entry Acquire when Available is
      begin
         Available := False;
      end Acquire;

      procedure Release is
      begin
         Available := True;
      end Release;

   end Binary_Semaphore;

end Bounded_Buffer;

-- test.adb
with Ada.Text_IO;
with Bounded_Buffer;

procedure Test is

   Buffer : Bounded_Buffer.Buffer_Type;

   task Writer;
   task body Writer is
   begin
      for I in 1 .. 50 loop
         Bounded_Buffer.Put (Buffer, I);
      end loop;

      Bounded_Buffer.Put (Buffer, 0);
   end Writer;

   task Reader;
   task body Reader is
      I : Integer;
   begin
      loop
         Bounded_Buffer.Get (Buffer, I);
         exit when I = 0;
         Ada.Text_IO.Put (Integer'Image (I));
         Ada.Text_IO.New_Line;
      end loop;
   end Reader;

begin
   null;
end Test;


I would like to ask you to comment/criticize on the above.
(The test.adb driver is provided just to sanity-check the rest.)

Note that in this example the shared data (Storage component of the
Buffer object) is accessed directly from concurrent subprograms.
Protecting this access is not necessary on the basis that binary
semaphores provide necessary exclusion and signalling (ordering). With
buffer of capacity > 1 the storage array and top/bottom indices would
be encapsulated by another protected object.

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

Re: Ravenscar-compliant bounded buffer

[Steve]

While I don't know much about the Ravenscar profile (other than what it is) 
I am famialar with the use of protected types.

The sample code is a good illustration of "abstraction inversion".  I know 
this because I posted similar code on this group several years ago and that 
is how it was described.

The code uses a high level abstraction "protected type" to create a low leve 
abstraction "Binary_Semaphore".  The code uses two semaphores to restrict 
access to the bounded buffer.  In this simple example it is easy to follow, 
but in a more complex example pairing Acquire's and Release's can be a 
chore.

Consider an alternate implementation:

-- bounded_buffer.ads
package Bounded_Buffer is

   type Buffer_Type is limited private;

   procedure Put (Buffer : in out Buffer_Type; Item : in Integer);
   procedure Get (Buffer : in out Buffer_Type; Item : out Integer);

private
   protected type Exclusive_Access is
      entry Put (Buffer : in out Buffer_Type; Item : in Integer);
      entry Get (Buffer : in out Buffer_Type; Item : out Integer);
   private
      Available_For_Reading : Boolean := False;
      Available_For_Writing : Boolean := True;
   end Exclusive_Access;

   type Buffer_Type is limited record
      Storage : Integer;
      Protected_Access : Exclusive_Access;
   end record;

end Bounded_Buffer;

-- bounded_buffer.adb
package body Bounded_Buffer is

   protected body Exclusive_Access is
      entry Put (Buffer : in out Buffer_Type; Item : in Integer) when 
Available_For_Writing is
      begin
         Buffer.Storage := Item;
         Available_For_Reading := True;
         Available_For_Writing := False;
      end Put;
      entry Get (Buffer : in out Buffer_Type; Item : out Integer) when 
Available_For_Reading is
      begin
         Item := Buffer.Storage;
         Available_For_Reading := False;
         Available_For_Writing := True;
      end Get;
   end Exclusive_Access;

   procedure Put (Buffer : in out Buffer_Type; Item : in Integer) is
   begin
      Buffer.Protected_Access.Put( Buffer, Item );
   end Put;

   procedure Get (Buffer : in out Buffer_Type; Item : out Integer) is
   begin
      Buffer.Protected_Access.Get( Buffer, Item );
   end Get;

end Bounded_Buffer;

----------------------------------
Here a single Exclusive_Access protected type is used to restrict access to 
the buffer.
It avoids the situation that you will run into with "who's not releasing the 
semaphore".

BTW: I apologize for my choice of type and variable names, I didn't spend 
much time thinking about them.

Regards,
Steve
(The Duck)

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:1188914005.607732.277400@57g2000hsv.googlegroups.com...
> In one of my previous posts I have criticized example 12 from the
> Ravenscar document.
> It makes sense to criticize constructively, I think. :-)
>
> -- bounded_buffer.ads
> package Bounded_Buffer is
>
>   type Buffer_Type is limited private;
>
>   procedure Put (Buffer : in out Buffer_Type; Item : in Integer);
>   procedure Get (Buffer : in out Buffer_Type; Item : out Integer);
>
> private
>
>   protected type Binary_Semaphore (Initial_State : Boolean) is
>      entry Acquire;
>      procedure Release;
>   private
>      Available : Boolean := Initial_State;
>   end Binary_Semaphore;
>
>   type Buffer_Type is limited record
>      Storage : Integer;
>      Available_For_Reading : Binary_Semaphore (Initial_State =>
> False);
>      Available_For_Writing : Binary_Semaphore (Initial_State =>
> True);
>   end record;
>
> end Bounded_Buffer;
>
> -- bounded_buffer.adb
> package body Bounded_Buffer is
>
>   procedure Put (Buffer : in out Buffer_Type; Item : in Integer) is
>   begin
>      Buffer.Available_For_Writing.Acquire;
>      Buffer.Storage := Item;
>      Buffer.Available_For_Reading.Release;
>   end Put;
>
>   procedure Get (Buffer : in out Buffer_Type; Item : out Integer) is
>   begin
>      Buffer.Available_For_Reading.Acquire;
>      Item := Buffer.Storage;
>      Buffer.Available_For_Writing.Release;
>   end Get;
>
>   protected body Binary_Semaphore is
>
>      entry Acquire when Available is
>      begin
>         Available := False;
>      end Acquire;
>
>      procedure Release is
>      begin
>         Available := True;
>      end Release;
>
>   end Binary_Semaphore;
>
> end Bounded_Buffer;
>
> -- test.adb
> with Ada.Text_IO;
> with Bounded_Buffer;
>
> procedure Test is
>
>   Buffer : Bounded_Buffer.Buffer_Type;
>
>   task Writer;
>   task body Writer is
>   begin
>      for I in 1 .. 50 loop
>         Bounded_Buffer.Put (Buffer, I);
>      end loop;
>
>      Bounded_Buffer.Put (Buffer, 0);
>   end Writer;
>
>   task Reader;
>   task body Reader is
>      I : Integer;
>   begin
>      loop
>         Bounded_Buffer.Get (Buffer, I);
>         exit when I = 0;
>         Ada.Text_IO.Put (Integer'Image (I));
>         Ada.Text_IO.New_Line;
>      end loop;
>   end Reader;
>
> begin
>   null;
> end Test;
>
>
> I would like to ask you to comment/criticize on the above.
> (The test.adb driver is provided just to sanity-check the rest.)
>
> Note that in this example the shared data (Storage component of the
> Buffer object) is accessed directly from concurrent subprograms.
> Protecting this access is not necessary on the basis that binary
> semaphores provide necessary exclusion and signalling (ordering). With
> buffer of capacity > 1 the storage array and top/bottom indices would
> be encapsulated by another protected object.
>
> --
> Maciej Sobczak
> http://www.msobczak.com/
> 

Re: Ravenscar-compliant bounded buffer

[Maciej Sobczak]

On 5 Wrz, 05:00, "Steve" <nospam_steve...@comcast.net> wrote:

> While I don't know much about the Ravenscar profile

:-)

In particular, one of the constituents of the Ravenscar profile is
this:

pragma Restrictions (Max_Protected_Entries => 1);

which explains the whole issue.

Bounded buffer is obvious to implement without the above restriction
and I completely agree that using two separate protected objects is an
"abstraction inversion".
The problem is that to be compliant with the Ravenscar profile a
protected type can have *at most one entry* - the rest is really a
question about the "correct hack" that has to be applied for typical
shared resource patterns.

I argue that my hack is better (more readable and easier to analyze)
than the original hack presented in example 12 of the Ravenscar
document.

I will not argue that any of these hacks is better than the
straightforward implementation with two entries, but I can accept the
statement that this is the price for having a uniform convention that
pays off in general, although not necessarily in this particular case.

Still, since I'm new to Ada, I welcome any comment that can help me
understand it better.

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

Re: Ravenscar-compliant bounded buffer

[Dmitry A. Kazakov]

On Tue, 4 Sep 2007 20:00:13 -0700, Steve wrote:

> While I don't know much about the Ravenscar profile (other than what it is) 
> I am famialar with the use of protected types.
> 
> The sample code is a good illustration of "abstraction inversion".  I know 
> this because I posted similar code on this group several years ago and that 
> is how it was described.
> 
> The code uses a high level abstraction "protected type" to create a low leve 
> abstraction "Binary_Semaphore".  The code uses two semaphores to restrict 
> access to the bounded buffer.  In this simple example it is easy to follow, 
> but in a more complex example pairing Acquire's and Release's can be a 
> chore.

That is because of the Ravenscar limitation of one entry per protected
object. The solution Maciej presented is based on splitting one protected
object of two entries into two, each controlling access to its end of FIFO.
Protected objects don't compose so the result. Worse it will be with FIFO
size > 1. 

Here is a solution based on event + requeue rather than mutexes. Requeue is
implicit of course, because Ravenscar forbids requeue statements.

pragma Profile (Ravenscar);

package Bounded_Buffer is
   subtype Multiple is Positive range 2..Positive'Last;
   type Buffer_Type (Size : Multiple) is limited private;

   procedure Get (Buffer : in out Buffer_Type; Item : out Integer);
   procedure Put (Buffer : in out Buffer_Type; Item : Integer);

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

   protected type Buffer_Type (Size : Multiple) is
      entry Wait;
      procedure Get (Item : out Integer; Success : out Boolean);
      procedure Put (Item : Integer; Success : out Boolean);
   private
      Storage   : Storage_Data (1..Size);
      First_In  : Positive := 1;
      First_Out : Positive := 1;
      Empty     : Boolean  := True;
      Free      : Boolean  := False; -- In /= Out explicitly
   end Buffer_Type;
   
end Bounded_Buffer;

Notes:

1. First_In /= First_Out is a complex barrier, so we need it explicitly as
Free.

2. With buffer size 1 this implementation would do busy waiting, for this
reason the minimal buffer size is 2.

package body Bounded_Buffer is

   protected body Buffer_Type is

      entry Wait when Free is
      begin
         null;
      end Wait;

      procedure Put (Item : in Integer; Success : out Boolean) is
      begin
         if Free or else Empty then
            Storage (First_Out) := Item;
            if First_Out = Size then
               First_Out := 1;
            else
               First_Out := First_Out + 1;
            end if;
            Free    := First_Out /= First_In;
            Empty   := False;
            Success := True;
         else
            Success := False;
         end if;
      end Put;

      procedure Get (Item : out Integer; Success : out Boolean) is
      begin
         if Free or else not Empty then
            Item := Storage (First_In);
            if First_In = Size then
               First_In := 1;
            else
               First_In := First_In + 1;
            end if;
            Free    := First_Out /= First_In;
            Empty   := not Free;
            Success := True;
         else
            Success := False;
         end if;
      end Get;
   end Buffer_Type;

   procedure Put (Buffer : in out Buffer_Type; Item : in Integer) is
      Success : Boolean;
   begin
      loop
         Buffer.Put (Item, Success);
         exit when Success;
         Buffer.Wait;
      end loop;
   end Put;
   
   procedure Get (Buffer : in out Buffer_Type; Item : out Integer) is
      Success : Boolean;
   begin
      loop
         Buffer.Get (Item, Success);
         exit when Success;
         Buffer.Wait;
      end loop;
   end Get;

end Bounded_Buffer;

-----------------------
P.S. As a general note. This object might interesting as an exercise, but
not likely needed. In a real application it would be strange to expect
multiple consumers taking integers out of buffer in some unpredictable
order. Normally, it is so that either there is one producer and one or many
consumers (like in distribution of jobs), or else there is many producers
and one consumer (like writing to log file). This might sufficiently
simplify the design. Yet another variant is multiple consumers receiving
whole waveform of integers put to the buffer (broadcasting). This would be
more difficult.

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

Re: Ravenscar-compliant bounded buffer

[brodax]

As I wrote in a previous post, I would suggest always thinking in
terms of building blocks: sporadic entities, cyclic entities and
(entry-less) protected entities. By following this approach you have
several main advantages: for example the system is *practically*
amenable to static timing analysis.

Just to make an example of a sporadic building block:

generic
   with procedure Sporadic_Operation;
   Task_Priority : Priority;
   --minimum interarrival time
   MAT : Positive;
   Max_Pending : Positive;
package Sporadic_Entity is

   -- Invoking this procedure release the sporadic task
   procedure Release;

private

   protected type Protocol is
      entry Wait(Release_Time : out Time);
      procedure Release;
   private
      Barrier : Boolean := False;
      Pending : Integer := 0;
   end Protocol;

   task type Thread(P : Priority; Interval : Positive) is
     pragma Priority(P);
   end Thread;

   T : Thread(Task_Priority, MAT);

end Sporadic_Entity;


package body Sporadic_Entity is

   P : Protocol;

   -------------
   -- Release --
   -------------

   procedure Release is
   begin
      P.Release;
   end Release;

   --------------
   -- Protocol --
   --------------

   protected body Protocol is

      procedure Update_Barrier is
      begin
         Barrier := (Pending > 0);
      end Update_Barrier;

      ----------
      -- Wait --
      ----------

      entry Wait(Release_Time : out Time) when Barrier is
      begin
         Release_Time := Clock;
         Pending := Pending - 1;
         Update_Barrier;
      end Wait;

      -------------
      -- Release --
      -------------

      procedure Release is
      begin
         if Pending < Max_Pending then
            Pending := Pending + 1;
            Update_Barrier;
         end if;
      end Release;

   end Protocol;

   ------------
   -- Thread --
   ------------

   task body Thread is
      Next_Time : Time := System_Release_Time;
      --  System_Release_Time is a system-wide constant specifying the
release time of all
      --+ tasks in the system
   begin
      delay until Next_Time;
      loop
         P.Wait(Next_Time);
         Sporadic_Operation;
         Next_Time := Next_Time + Milliseconds(MAT);
         delay until Next_Time;
      end loop;
   end Thread;

end Sporadic_Entity;

Basically the sporadic building block let you instantiate a Ravenscar
compliant sporadic task enforcing a minimum interarrival time. Please
note that with this pattern you are sure by construction that at most
1 task is queued on an entry. The pattern can be easily extended to
include parameters for the sporadic operation (just put a queue where
parameters are stored inside Protocol). The Reader/Writer are
naturally sporadic, as they are release by an event (the buffer is non-
empty/non-full). The Buffer is an entry-less protected object. Then
you can put the logic for the release of the Reader/Writer inside the
buffer: for example, every time the Writer writes a value, it may
release the Reader (by invoking Reader.Release); and the Writer is
released either by writing on a non-full (after writing) buffer or by
the Reader when it reads on the last position of the buffer (the state
of the buffer changes from full to non-full).

Re: Ravenscar-compliant bounded buffer

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> P.S. As a general note. This object might interesting as an exercise, but
> not likely needed. In a real application it would be strange to expect
> multiple consumers taking integers out of buffer in some unpredictable
> order. Normally, it is so that either there is one producer and one or many
> consumers (like in distribution of jobs), or else there is many producers
> and one consumer (like writing to log file). This might sufficiently
> simplify the design. Yet another variant is multiple consumers receiving
> whole waveform of integers put to the buffer (broadcasting). This would be
> more difficult.
> 
Anyway, your solution is Ravenscar compliant only if there is exactly 
one producer and one consumer, otherwise there is a possibility of 
having more than one task on the entry queue.

For those who might wonder:
The limitation on only one task per queue is intended to guarantee 
bounded waiting time. Any solution that tries to work around the 
Ravenscar rules in order to have longer queues will violate this 
restriction at some point, or have to manage explicit lists - thus 
violating the spirit of the profile!

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ravenscar-compliant bounded buffer

[Steve]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:1188977891.197536.21660@r29g2000hsg.googlegroups.com...
> On 5 Wrz, 05:00, "Steve" <nospam_steve...@comcast.net> wrote:
>
>> While I don't know much about the Ravenscar profile
>
> :-)
>
> In particular, one of the constituents of the Ravenscar profile is
> this:
>
> pragma Restrictions (Max_Protected_Entries => 1);
>
> which explains the whole issue.
>
> Bounded buffer is obvious to implement without the above restriction
> and I completely agree that using two separate protected objects is an
> "abstraction inversion".
> The problem is that to be compliant with the Ravenscar profile a
> protected type can have *at most one entry* - the rest is really a
> question about the "correct hack" that has to be applied for typical
> shared resource patterns.
>

Very interesting.  A profile that promotes obscurity.

> I argue that my hack is better (more readable and easier to analyze)
> than the original hack presented in example 12 of the Ravenscar
> document.
>

Given the restriction, I found your example easy to follow.  I don't know 
where to find the Ravenscar document for comparison.

> I will not argue that any of these hacks is better than the
> straightforward implementation with two entries, but I can accept the
> statement that this is the price for having a uniform convention that
> pays off in general, although not necessarily in this particular case.
>

Ada 83 was restrictive in ways that were found to be overly restrictive for 
practical application.  Some of these retrictions were relaxed with Ada 95. 
Perhaps the next round of Ravenscar will do the same.

While I am not expert on protected types, it is my experience that the 
predictability of a protected type has more to do with the complexity than 
the number of entries.  Of course that doesn't matter if you must follow 
Ravenscar.

Regards,
Steve

> Still, since I'm new to Ada, I welcome any comment that can help me
> understand it better.
>
> --
> Maciej Sobczak
> http://www.msobczak.com/
> 

Re: Ravenscar-compliant bounded buffer

[Robert A Duff]

"Steve" <nospam_steved94@comcast.net> writes:

> Given the restriction, I found your example easy to follow.  I don't know 
> where to find the Ravenscar document for comparison.

The Ravenscar profile is documented in section D.13.1 of the latest Ada
Reference Manual.

> Ada 83 was restrictive in ways that were found to be overly restrictive for 
> practical application.  Some of these retrictions were relaxed with Ada 95. 
> Perhaps the next round of Ravenscar will do the same.

I don't see any need to relax Ravenscar, because if you want to use
features not allowed by Ravenscar, you don't have to restrict yourself
to Ravenscar.  It's a free choice.  I suppose we could argue about
whether the exact set of restrictions is appropriate, but the whole
point is to be restrictive, so the run-time system can be simplified (as
compared to a run-time system that supports full Ada).

- Bob

Re: Ravenscar-compliant bounded buffer

[Dmitry A. Kazakov]

On Thu, 06 Sep 2007 10:06:51 -0400, Robert A Duff wrote:

> I suppose we could argue about
> whether the exact set of restrictions is appropriate, but the whole
> point is to be restrictive, so the run-time system can be simplified (as
> compared to a run-time system that supports full Ada).

Aha, to ease your life. Others might have thought it was for us, poor
users... (:-))

No, seriously, the point about abstraction inversion stands. And other
posts about tasks classification into periodic, sporadic etc only support
it. So the question is whether these are hard limits or just the current
state of the art.

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

Re: Ravenscar-compliant bounded buffer

[Maciej Sobczak]

On 6 Wrz, 16:06, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> the whole
> point is to be restrictive, so the run-time system can be simplified (as
> compared to a run-time system that supports full Ada).

Does GNAT provide somewhat simpler (smaller? faster?) runtime for
programs that declare compliance with the Ravenscar profile?
I'm not asking about the high-integrity edition of GNAT, but the
"normal" one.

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

Re: Ravenscar-compliant bounded buffer

[Steve]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccps0vkhvo.fsf@shell01.TheWorld.com...
> "Steve" <nospam_steved94@comcast.net> writes:
>
>> Given the restriction, I found your example easy to follow.  I don't know
>> where to find the Ravenscar document for comparison.
>
> The Ravenscar profile is documented in section D.13.1 of the latest Ada
> Reference Manual.
>

Unless I'm looking the wrong place, section D.13.1 of the ARM (on AdaIC) 
just lists the restrictions.  The original post was asking about the clarity 
of an example in a specific document.

>> Ada 83 was restrictive in ways that were found to be overly restrictive 
>> for
>> practical application.  Some of these retrictions were relaxed with Ada 
>> 95.
>> Perhaps the next round of Ravenscar will do the same.
>
> I don't see any need to relax Ravenscar, because if you want to use
> features not allowed by Ravenscar, you don't have to restrict yourself
> to Ravenscar.  It's a free choice.  I suppose we could argue about
> whether the exact set of restrictions is appropriate, but the whole
> point is to be restrictive, so the run-time system can be simplified (as
> compared to a run-time system that supports full Ada).

The choice of the exact set of restrictions that are appropriate is what may 
in practice make sense to change.  After some experience with the 
restrictions it may be found that a minor modification to one of the 
restrictions may reduce complexity of implementations.

Regards,
Steve

>
> - Bob 

Re: Ravenscar-compliant bounded buffer

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 06 Sep 2007 10:06:51 -0400, Robert A Duff wrote:
>
>> I suppose we could argue about
>> whether the exact set of restrictions is appropriate, but the whole
>> point is to be restrictive, so the run-time system can be simplified (as
>> compared to a run-time system that supports full Ada).
>
> Aha, to ease your life. Others might have thought it was for us, poor
> users... (:-))

Yeah, I see the smiley.  But seriously, simpler run-time system means
easier to verify that it does what's intended.  I suppose that's good
for users of it, unless they need reimplement all of Ada "by hand" on
top of the supposedly simpler run-time system.

> No, seriously, the point about abstraction inversion stands.

Agreed.  As I said, it's a choice.  If you really need to put multiple
tasks on entry queues, then you probably don't want Ravenscar.  If you
can easily live with the limitations of Ravenscar, you might benefit
from the simplicity.

>...And other
> posts about tasks classification into periodic, sporadic etc only support
> it. So the question is whether these are hard limits or just the current
> state of the art.

- Bob

Re: Ravenscar-compliant bounded buffer

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 6 Wrz, 16:06, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> the whole
>> point is to be restrictive, so the run-time system can be simplified (as
>> compared to a run-time system that supports full Ada).
>
> Does GNAT provide somewhat simpler (smaller? faster?) runtime for
> programs that declare compliance with the Ravenscar profile?

I think so, but I'm not sure.  I'm still pretty new at AdaCore, and I
don't really understand all the different versions and configurations.
Ask AdaCore!

- Bob

Re: Ravenscar-compliant bounded buffer

[Robert A Duff]

"Steve" <nospam_steved94@comcast.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccps0vkhvo.fsf@shell01.TheWorld.com...
>> "Steve" <nospam_steved94@comcast.net> writes:
>>
>>> Given the restriction, I found your example easy to follow.  I don't know
>>> where to find the Ravenscar document for comparison.
>>
>> The Ravenscar profile is documented in section D.13.1 of the latest Ada
>> Reference Manual.
>>
>
> Unless I'm looking the wrong place, section D.13.1 of the ARM (on AdaIC) 
> just lists the restrictions.

Right.  And then you can look up each restriction, and see what it
specifically means.

>...The original post was asking about the clarity 
> of an example in a specific document.

Sorry.  I guess I was confused about what you were asking for.

>>> Ada 83 was restrictive in ways that were found to be overly restrictive 
>>> for
>>> practical application.  Some of these retrictions were relaxed with Ada 
>>> 95.
>>> Perhaps the next round of Ravenscar will do the same.
>>
>> I don't see any need to relax Ravenscar, because if you want to use
>> features not allowed by Ravenscar, you don't have to restrict yourself
>> to Ravenscar.  It's a free choice.  I suppose we could argue about
>> whether the exact set of restrictions is appropriate, but the whole
>> point is to be restrictive, so the run-time system can be simplified (as
>> compared to a run-time system that supports full Ada).
>
> The choice of the exact set of restrictions that are appropriate is what may
> in practice make sense to change.  After some experience with the 
> restrictions it may be found that a minor modification to one of the 
> restrictions may reduce complexity of implementations.

Yes, it might.

There's a trade-off in complexity of implementation (of the Ada run-time
system) and complexity of applications.  It's not at all clear (to me)
where that line should be drawn.

- Bob

Re: Ravenscar-compliant bounded buffer

[anon]

>Does GNAT provide somewhat simpler (smaller? faster?) runtime for
>programs that declare compliance with the Ravenscar profile?

The simple answer is No. Mostly it included in the GNAT PRO version 
only. 


The GPL/GNU GNAT Ada system has three main operating environments.  

 1) Normal "run-time system" (RTS) which handles most 
    non-mission critical partitions. Just compile/bind/link 
    and execute the programs.

 2) Is defined in the GNAT manual as an obsolete feature, that is 
    using the "pragma No_Run_Time ;", but still works.  In this 
    version, the user must supply the RTS subsystem that the 
    program requires. This does decrease the file size to about 
    25 % of the normal compile version and in some cases will 
    increase the performance with other pragma used. But the 
    programmer must write all procedures and functions for each 
    RTS package that the program uses.

    A very simple example of this type of RTS version:

---------------
-- Hello.adb --
---------------
-- File size: using Ada.Text_IO              => 251 KB
-- File size: using GNAT.IO                  => 192 KB
-- File size: using "pragma No_Run_Time" 
--            with user create RTS package   => 58 KB
--
-- Note: size may differ between operating systems and 
--       GNAT versions but the concept is the same.
--
-- And due to decrease packages requirements and code 
-- generated the performance will increase from using 
-- Ada.Text_IO to GNAT.IO to the user define RTS subsystem.
-- 
-- compile => gcc -c put_line.c 
--            gnat compile hello.adb
--            gnat bind hello.ali
--            gnat link hello.ali   put_line.o
-- 
-- run     => ./hello
-- 
---------------
-- Hello.adb --
---------------
pragma No_Run_Time ;
--
-- Ada.Text_IO aka Text_IO and GNAT.IO packages
-- are illegal with the usage of "No_Run_Time"
--
--  with Ada.Text_IO; use Ada.Text_IO;
--  with GNAT.IO ; use GNAT.IO ;
--
procedure Hello is

   --
   -- External link for put_line RTS subsystem package 
   -- Note: String needs to terminate with ascii.nul
   --
   -- comment out to use GNAT packages 
   --
   procedure Put_Line ( Value : String ) ;
   pragma Import ( C, Put_Line, "put_line" ) ;
  
  begin
    Put_Line ( "Hello World. Welcome to GNAT" & ASCII.NUL ) ;
  end ;


/* ----------- */
/*  put_line.c */
/* ----------- */
#include <stdio.h>

/* put_line -- run-time subsystem procedure */
void put_line ( value )
char * value ;
  {
    printf ( "%s\n", value ) ;
  }
/* --eof-- */


 3) Is the Ravenscar RTS. It can contains multiple packages each 
    fine tuned for Real-Time operating environment (RTOE) and the 
    full criteria of the DO-178B. The academic and GPL/GNU 
    versions do not meet the DO-178B criteria or have RTOE packages 
    for the Ravenscar profile.

    The compiler does set the correct restrictions when using the 
    Ravenscar profile. And some of these restrictions will increase 
    the performance in some case. But linking is still done with the
    Normal or "No Run Time" RTS, so the performance will be limited.


Now, there are a few other pragmas that can decrease the program's
file size or the amount its allocated during execution. Some of 
these might increase the programs performance but it is normally 
not enough to spend a great deal of time on. That is, unless 
your allocating large block of memory for vector or matrix 
project and need to speed up the allocation schemes. But you may 
have to write the allocation routines.



Something you could try.  The next time you write a program that 
you thinks meet the Ravenscar profile designed add either the 
"pragma Ravenscar ;" or some of the main Ravenscar profile 
restrictions to your code.  If your in class this might turn into 
an extra assignment or it could be used in a later course.


n <1189113180.100290.51880@50g2000hsm.googlegroups.com>,  Maciej Sobczak <see.my.homepage@gmail.com> writes:
>On 6 Wrz, 16:06, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> the whole
>> point is to be restrictive, so the run-time system can be simplified (as
>> compared to a run-time system that supports full Ada).
>
>Does GNAT provide somewhat simpler (smaller? faster?) runtime for
>programs that declare compliance with the Ravenscar profile?
>I'm not asking about the high-integrity edition of GNAT, but the
>"normal" one.
>
>--
>Maciej Sobczak
>http://www.msobczak.com/
>

Re: Ravenscar-compliant bounded buffer

[Maciej Sobczak]

On 7 Wrz, 13:56, a...@anon.org (anon) wrote:

>  2) Is defined in the GNAT manual as an obsolete feature, that is
>     using the "pragma No_Run_Time ;", but still works.  In this
>     version, the user must supply the RTS subsystem that the
>     program requires.

Interesting, but IO is easy. What about multitasking? What kind of RTS
needs to be supplied for tasks to work correcly?


> /* ----------- */
> /*  put_line.c */
> /* ----------- */
> #include <stdio.h>
>
> /* put_line -- run-time subsystem procedure */
> void put_line ( value )
> char * value ;
>   {
>     printf ( "%s\n", value ) ;
>   }
> /* --eof-- */

Note that this requires the C run-time instead. It might be smaller/
faster, but still it is not No_Run_Time in the strict sense. You might
need to really use the basic OS services directly to claim "no run-
time" program. Or even forget about OS, the No_Run_Time option is most
likely intended for those who program hardware directly.

> If your in class this might turn into
> an extra assignment or it could be used in a later course.

No, I'm not "in class". :-)

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

Re: Ravenscar-compliant bounded buffer

[anon]

To use tasking you have to build that code as well. Unless you use the 
Normal run-time system for the non-Pro version compiler. And 
"No_Run_time" will kill that process.

And Yes, if you use the "No_Run_Time" prgama you could build a device 
driver for some hardware. A better idea is to build your own RTS. You 
would think that in 15 years of GNAT you might see a few new RTS or 
at least one or two doctoral types of RTS, but nothing. The only thing you 
see is mostly ports of GNAT to a new hardware or operating system.

>Note that this requires the C run-time instead. 

I could of wrote the code in Assembly bypassing the "C run-time" but for 
a demonstration it was not needed. And the assembly package might be 
smaller and faster. Plus if you look at GNAT.IO package you will see that 
it calls some routines that are written in C which source code is in file 
"cio.c" that even Ada.Text_IO uses. Actually GNAT uses the C's "fprintf" 
instead of "prinf".

Note: GNAT uses the GCC "C Run-Time" package to make it easier to 
be installed on a number of different operating systems and processors.

If you look around in the other Ada packages and C source code files you 
will see just how the tasking is done which is basically just a number of 
OS "thread" routines calls linking to Ada by way of C.

And the GNU/GPL GNAT Ada is just a frontend compiler to the GCC.  If 
you look at the source code "Back_end.adb" you will see a link to a C 
coded procedure called gigi (gnat-to-gcc) which calls the C "Run-Time" 
compiler. The C "Run-Time" compiler then converts the GNAT C 
generated code to the object modules.

For GNAT and most other Ada systems there is no Ada only "Run-Time 
System". Most uses the "C library" packages, some may use assembly
or JAVA or even Pascal library packages for its RTS.



In <1189194299.326741.151840@50g2000hsm.googlegroups.com>,  Maciej Sobczak <see.my.homepage@gmail.com> writes:
>On 7 Wrz, 13:56, a...@anon.org (anon) wrote:
>
>>  2) Is defined in the GNAT manual as an obsolete feature, that is
>>     using the "pragma No_Run_Time ;", but still works.  In this
>>     version, the user must supply the RTS subsystem that the
>>     program requires.
>
>Interesting, but IO is easy. What about multitasking? What kind of RTS
>needs to be supplied for tasks to work correcly?
>
>
>> /* ----------- */
>> /*  put_line.c */
>> /* ----------- */
>> #include <stdio.h>
>>
>> /* put_line -- run-time subsystem procedure */
>> void put_line ( value )
>> char * value ;
>>   {
>>     printf ( "%s\n", value ) ;
>>   }
>> /* --eof-- */
>
>Note that this requires the C run-time instead. It might be smaller/
>faster, but still it is not No_Run_Time in the strict sense. You might
>need to really use the basic OS services directly to claim "no run-
>time" program. Or even forget about OS, the No_Run_Time option is most
>likely intended for those who program hardware directly.
>
>> If your in class this might turn into
>> an extra assignment or it could be used in a later course.
>
>No, I'm not "in class". :-)
>
>--
>Maciej Sobczak
>http://www.msobczak.com/
>

Re: Ravenscar-compliant bounded buffer

[Larry Kilgallen]

In article <TRlEi.505983$p47.38772@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:

> For GNAT and most other Ada systems there is no Ada only "Run-Time 
> System". Most uses the "C library" packages, some may use assembly
> or JAVA or even Pascal library packages for its RTS.

Certainly DEC/Compaq/HP Ada has its own runtime library, purpose-built
for Ada support.  It does rely on underlying operating system features,
but there is a lot of Ada-specificity in the way they are used.

Re: Ravenscar-compliant bounded buffer

[anon]

The DEC as I posted about the history of DEC and Ada before stated that 
they created the close source Ada libraries, that were originally written 
in C. Later the compiler was rewritten in Ada once the C version of an 
Ada compiler was operational, but even today most of the library core 
routines are still in C.

What I was trying to hint at without beating someone up about it was 
that the C code files should go.  Links to the Operating System and 
hardware drivers should be direct though use of the "Import pragma" 
not though a C interface driver file like GNAT and yes, and DEC 
still uses. And the C libraries need to be rewritten in Ada.

But for GNAT and other Ada's systems that are supported on a 
muti-platform environments that means that instead of using C 
conditional statements in one file, the authors would have to 
recreate a platform specific Ada package for each platform and the 
authors would prefer not to. Plus, that could mean a break from 
GCC and its code structures for GNAT. 

Now for an operating systems or kernels that is wriiten in Ada that you 
can download and use, there are two Posix Real-Time systems out there.
The first is the MaRTE and the second is RTERMS. But both of these 
rely on a set of C files for booting and to handle the processors 
interrupts. Actually the GNAT compiler even has packages and links 
for both kernel in its files structures.



In <5BwKkEXdYLCt@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>In article <TRlEi.505983$p47.38772@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>
>> For GNAT and most other Ada systems there is no Ada only "Run-Time 
>> System". Most uses the "C library" packages, some may use assembly
>> or JAVA or even Pascal library packages for its RTS.
>
>Certainly DEC/Compaq/HP Ada has its own runtime library, purpose-built
>for Ada support.  It does rely on underlying operating system features,
>but there is a lot of Ada-specificity in the way they are used.

Re: Ravenscar-compliant bounded buffer

[Niklas Holsti]

anon wrote:

> And the GNU/GPL GNAT Ada is just a frontend compiler to the GCC.  If 
> you look at the source code "Back_end.adb" you will see a link to a C 
> coded procedure called gigi (gnat-to-gcc) which calls the C "Run-Time" 
> compiler. The C "Run-Time" compiler then converts the GNAT C 
> generated code to the object modules.

Saying that GNAT generates C code is nonsense, as you have been 
answered earlier on this newsgroup. The GU Compiler Collection has 
a common internal program representation that interfaces the front 
ends to the back end, but this representation is not C.

> For GNAT and most other Ada systems there is no Ada only "Run-Time 
> System".

That does not agree with my experience. Two of the three Ada 
systems for embedded platforms that I have used have had their own 
Ada RTS: TLD Ada and XGC Ada. XGC Ada is based on the GNAT compiler 
but has its own kernel and libraries (mostly written in Ada, too, 
as far as I remember).

The third compiler was DEC Ada. I used it for applications on a 
microVAX under VMS but as I remember it could also create programs 
to run on a simpler real-time kernel called VAXELN. I think VAXELN 
was not written in Ada and could also be used from other languages. 
And why not.

Then there is the Open Ravenscar Kernel ORK for GNAT, 
http://polaris.dit.upm.es/~ork/, also written in Ada.

For general (workstation, server) platforms of course Ada vendors 
do the sensible thing and connect to the existing OS interfaces, in 
most cases designed for C as the lowest common denominator.

There have been full-Ada systems even outside the embedded domain. 
Long ago, when Nokia (yes, the mobile phone company) was selling 
computers they developed a 32-bit system called MPS10 to compete 
with VAXes for data processing applications. The software, 
including the OS and database system, was in Ada.

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

Re: Ravenscar-compliant bounded buffer

[Pascal Obry]

Niklas Holsti a �crit :
> Saying that GNAT generates C code is nonsense, as you have been answered
> earlier on this newsgroup. The GU Compiler Collection has a common

Well anon says thousand of wrong things but he did not say that GNAT
generates C code in its previous message :)

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: Ravenscar-compliant bounded buffer

[anon]

WHERE IS YOU PROOF!!! If your going to call a person a liar then you 
should provide proof it or just say that your a TROLL and be done with 
it. It seams that people here love to argue but give no proof of what 
they say.  At least I give proof of what I have said in history posts.

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. That can be printed as a C program. Also there 
are a few web sites with doctoral thesis that states this as well as 
a few papers at ACM. And ACM group will verify the information before 
accepting thesis paper and this is where I learn of it. The paper include 
a program that will print internal C as a compilable C source code 
file.

Now since, the mid 1980's most compiler are FRONT_END compilers aka 
a language translator that converts the source language to the system's 
main language, normal for today that's C with the exception of TI which 
used Pascal.  Then the FRONT_END compiler calls a BACK_END compiler 
(for GNAT this is done by the compiler calling "gigi" (gnat-to-gcc)), 
which re-calls the gcc compiler for GNU system so that the internal C 
can be converted to a object module or assembly source file. 
{{ continue below }}

Now, any system build around GNAT will contain the C code that GNAT 
uses to connect to the operating system. And since GNAT is built 
with the GCC libraries the trig. and other math functions will be 
wriiten in C to interface with the FPU or to the FPU emulation 
package, which is also written in C. That make any system that is 
compiled with around GNAT not "Ada only Run-Time System". 

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". 

>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.


Stated this before too!

First, the MicroVax came out in, the mid 1980s and DEC created Ada 
in 1978. So, your MicroVax Ada version could of been the third 
released or third version sold to the general public by DEC. 


>For general (workstation, server) platforms of course Ada vendors 
>do the sensible thing and connect to the existing OS interfaces, in 
>most cases designed for C as the lowest common denominator.
>
>There have been full-Ada systems even outside the embedded domain. 
>Long ago, when Nokia (yes, the mobile phone company) was selling 
>computers they developed a 32-bit system called MPS10 to compete 
>with VAXes for data processing applications. The software, 
>including the OS and database system, was in Ada.


And I was talking about multi-platforms, which I stated. Which means 
that the system must operate on more than one processor and platforms 
class system. Like Nokia's Ada on a NCR or Univac system, which did 
not happen. 

Note: this information come from Intel web site during the release of 
the Itanium I processor. { continue from above }

Before GNU system the idea of multi-platform compilers basically did 
not happen, but since then the major software houses have adopted this 
concept. A quick reason is that once they create a new processor they 
do not have to re-write all of the compiler codes and libraries. Just 
create the C compiler and recompile the software system from there.

Plus, as I have stated before getting a new licenses or paying for a 
Software Patents to re-write the close source libraries is a high 
Dollar item. And most companies and users do not want to pay
that price or take the time and expense to re-write the code. So 
C is used.



In <46e28a6a$0$27847$39db0f71@news.song.fi>, Niklas Holsti <niklas.holsti@nospam.please> writes:
>anon wrote:
>
>> And the GNU/GPL GNAT Ada is just a frontend compiler to the GCC.  If 
>> you look at the source code "Back_end.adb" you will see a link to a C 
>> coded procedure called gigi (gnat-to-gcc) which calls the C "Run-Time" 
>> compiler. The C "Run-Time" compiler then converts the GNAT C 
>> generated code to the object modules.
>
>Saying that GNAT generates C code is nonsense, as you have been 
>answered earlier on this newsgroup. The GU Compiler Collection has 
>a common internal program representation that interfaces the front 
>ends to the back end, but this representation is not C.
>
>> For GNAT and most other Ada systems there is no Ada only "Run-Time 
>> System".
>
>That does not agree with my experience. Two of the three Ada 
>systems for embedded platforms that I have used have had their own 
>Ada RTS: TLD Ada and XGC Ada. XGC Ada is based on the GNAT compiler 
>but has its own kernel and libraries (mostly written in Ada, too, 
>as far as I remember).
>
>The third compiler was DEC Ada. I used it for applications on a 
>microVAX under VMS but as I remember it could also create programs 
>to run on a simpler real-time kernel called VAXELN. I think VAXELN 
>was not written in Ada and could also be used from other languages. 
>And why not.
>
>Then there is the Open Ravenscar Kernel ORK for GNAT, 
>http://polaris.dit.upm.es/~ork/, also written in Ada.
>
>For general (workstation, server) platforms of course Ada vendors 
>do the sensible thing and connect to the existing OS interfaces, in 
>most cases designed for C as the lowest common denominator.
>
>There have been full-Ada systems even outside the embedded domain. 
>Long ago, when Nokia (yes, the mobile phone company) was selling 
>computers they developed a 32-bit system called MPS10 to compete 
>with VAXes for data processing applications. The software, 
>including the OS and database system, was in Ada.
>
>-- 
>Niklas Holsti
>Tidorum Ltd
>niklas holsti tidorum fi
>       .      @       .

Re: Ravenscar-compliant bounded buffer

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Just a TROLL! More on!

In <46E28F26.3030805@obry.net>, Pascal Obry <pascal@obry.net> writes:
>Niklas Holsti a �crit :
>> Saying that GNAT generates C code is nonsense, as you have been answered
>> earlier on this newsgroup. The GU Compiler Collection has a common
>
>Well anon says thousand of wrong things but he did not say that GNAT
>generates C code in its previous message :)
>
>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: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> WHERE IS YOU PROOF!!! If your going to call a person a liar then you 

Oh noes, he's writing caps again.

<snipped a lot of strange stuff about GNAT using C as backend and DEC in the Ada history>

> Before GNU system the idea of multi-platform compilers basically did 
> not happen, but since then the major software houses have adopted this 
> concept. A quick reason is that once they create a new processor they 

See PCC, the portable C compiler by
Johnson. E.g. http://en.wikipedia.org/wiki/Portable_C_Compiler for
further references.

Concerning your attempts to rewrite history concerning DEC and Ada: It
might be that you'r basing your comments on a possible pre
standardization involvment of DEC in the Ada development effort
between 1979 and 1983 when "Green" was finally chosen to become
Ada. Maybe DEC developed one of the Stoneman prototype
compilers. Information about this is difficult to find w/o deeper
research which I'm not in the mood to do now, and without you giving
any references (which you really should, given that you try to tell a
story that is different from what I know as accepted history). At the
very least you're emphasizing the part of DEC in Ada history beyond
all proportion (in another post some weeks ago you wrote something to
the effect that DEC owns Ada - WTF?). But the thing that makes be
really really suspicious is when you don't get thing right which (a) I
know better and (b) you could have found out with a bit research, I
even dare say: In some 10 years in the industry (and aren't you always
pretending you're such an old hand?) you could not have been able to
avoid learning some parts of the history, like about Johnson's
portable compiler.

So when everything is said and done, I begin to doubt especially the
things in your statements which cannot be checked immediately. 

And I would really appreciate if you stopped taking on a posture as an
expert and talk like "ex cathedra". There are simply to many half
truths and plain untruths in your grand sweeping oratories.

> do not have to re-write all of the compiler codes and libraries. Just 
> create the C compiler and recompile the software system from there.
>


-- Markus

Re: Ravenscar-compliant bounded buffer

[Larry Kilgallen]

In article <DbqEi.507138$p47.352055@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
> The DEC as I posted about the history of DEC and Ada before stated that 
> they created the close source Ada libraries, that were originally written 
> in C. Later the compiler was rewritten in Ada once the C version of an 
> Ada compiler was operational, but even today most of the library core 
> routines are still in C.

It is plain from reading the VMS Source Listings kit that the Ada RTL
is written in Bliss.

Since the compiler uses GEM on Alpha, certainly that part is in Bliss.

Re: Ravenscar-compliant bounded buffer

[anon]

That may be true for VMS but since the information that was certified 
by the DOD said C for Ada. And that the final word, because the DOD 
certified it was so.

Plus, VMS was "close source" only back then.  There is now a port called 
OpenVMS. As for the VMS version of Ada RTL written in Bliss, that 
also proves my point of no "Ada only Run-Time System".

An Alpha with GEM, well the Alpha was created in 1992. Not at the 
birth of Ada. But again GEM means no "Ada only Run-Time System".


In <3dUR1T8RzWhQ@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>In article <DbqEi.507138$p47.352055@bgtnsc04-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
>> The DEC as I posted about the history of DEC and Ada before stated that 
>> they created the close source Ada libraries, that were originally written 
>> in C. Later the compiler was rewritten in Ada once the C version of an 
>> Ada compiler was operational, but even today most of the library core 
>> routines are still in C.
>
>It is plain from reading the VMS Source Listings kit that the Ada RTL
>is written in Bliss.
>
>Since the compiler uses GEM on Alpha, certainly that part is in Bliss.

Re: Ravenscar-compliant bounded buffer

[Gautier]

anon wrote:
> WHERE IS YOU PROOF!!! If your going to call a person a liar then you 
> should provide proof it or just say that your a TROLL and be done with 
> it. It seams that people here love to argue but give no proof of what 
> they say.

Yeah, that's a problem, especially people who write things like:
 > And since GNAT is built
> with the GCC libraries the trig. and other math functions will be 
> wriiten in C to interface with the FPU or to the FPU emulation 
> package, which is also written in C.

...which is pretty easy to check that it is wrong: perhaps widely outdated, or 
just an unverified guess-work. In your GNAT adainclude directory, look at
	Ada.Numerics.Generic_Elementary_Functions,
body: a-ngelfu.adb, which refers to
	Ada.Numerics.Aux
body: a-numaux.adb which uses (at least the for x86) only machine code 
insertions to directly access the FPU - no C code around...
Apparently, before 1998 (when GNAT's Ada.Numerics.Aux began to exist), GNAT's 
Ada.Numerics.Generic_Elementary_Functions used only the C math.h code as the 
comment at the body's begin suggests, but it is no more the case for every 
platform since then.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ravenscar-compliant bounded buffer

[Gautier]

anon:

> 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. That can be printed as a C program. Also there 
> are a few web sites with doctoral thesis that states this as well as 
> a few papers at ACM. And ACM group will verify the information before 
> accepting thesis paper and this is where I learn of it. The paper include 
> a program that will print internal C as a compilable C source code 
> file.

You could write a program that outputs the tree as a compilable Ada source code, 
couldn't you ?

> Now since, the mid 1980's most compiler are FRONT_END compilers aka 
> a language translator that converts the source language to the system's 
> main language, normal for today that's C with the exception of TI which 
> used Pascal.  Then the FRONT_END compiler calls a BACK_END compiler 
> (for GNAT this is done by the compiler calling "gigi" (gnat-to-gcc)), 
> which re-calls the gcc compiler for GNU system so that the internal C 
> can be converted to a object module or assembly source file. 
> {{ continue below }}

Between the front-end and the back-end, a data tree is passed, not a C source 
code. As discussed earlier, there is no intermediary C code - please re-read and 
remember R. Dewar's explanation. As a mnemotechnic exercise, I cannot resist to 
quote this from c.l.a. (~1998):

"Repeat after me:  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
  GNAT does NOT produce C code.  GNAT does NOT produce C code. GNAT does NOT 
produce C code.  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
GNAT does NOT produce C code.  GNAT does NOT produce C code.  GNAT does NOT 
produce C code.  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
GNAT does NOT produce C code.
There.  Feel better now? :-)
"
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ravenscar-compliant bounded buffer

[anon]

Showing your TROLLISM!

If you check GNU GNAT 4.3 it contains 
Ada.Numerics.Aux -- for Vxworks which link into GCC C libraies.
Ada.Numerics.Aux -- for darwin also links to thier GCC C library.
All Ada.Numerics.Aux use the C code.
 

  GET OVER IT! YOU CAN NEVER PROVE THAT GNAT DOES NOT 
  INCLUDE LINK INTO THE GCC C LIBRARIES! AND THESE 
  LIBRARY ROUTINES ARE LINKED INTO YOU CODE IF YOU 
  NEED THOSE ROUTINES!


AND AS FOR YOUR OTHER POST NO PROVE EITHER! MINE PAPERS AT 
ACM.


In <46e3ccfd$1_4@news.bluewin.ch>, Gautier <gautier@fakeaddress.nil> writes:
>anon wrote:
>> WHERE IS YOU PROOF!!! If your going to call a person a liar then you 
>> should provide proof it or just say that your a TROLL and be done with 
>> it. It seams that people here love to argue but give no proof of what 
>> they say.
>
>Yeah, that's a problem, especially people who write things like:
> > And since GNAT is built
>> with the GCC libraries the trig. and other math functions will be 
>> wriiten in C to interface with the FPU or to the FPU emulation 
>> package, which is also written in C.
>
>....which is pretty easy to check that it is wrong: perhaps widely outdated, or 
>just an unverified guess-work. In your GNAT adainclude directory, look at
>	Ada.Numerics.Generic_Elementary_Functions,
>body: a-ngelfu.adb, which refers to
>	Ada.Numerics.Aux
>body: a-numaux.adb which uses (at least the for x86) only machine code 
>insertions to directly access the FPU - no C code around...
>Apparently, before 1998 (when GNAT's Ada.Numerics.Aux began to exist), GNAT's 
>Ada.Numerics.Generic_Elementary_Functions used only the C math.h code as the 
>comment at the body's begin suggests, but it is no more the case for every 
>platform since then.
>______________________________________________________________
>Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
>Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
>
>NB: For a direct answer, e-mail address on the Web site!

Re: Ravenscar-compliant bounded buffer

[Larry Kilgallen]

In article <dJIEi.79067$ax1.39061@bgtnsc05-news.ops.worldnet.att.net>, anon@anon.org (anon) writes:
> That may be true for VMS but since the information that was certified 
> by the DOD said C for Ada. And that the final word, because the DOD 
> certified it was so.

If there were a DoD document saying it was a box of magic pixies,
would you believe that ?

> Plus, VMS was "close source" only back then.

The status of VMS has not changed in that regard, except that those
who pay for the source listings now get them on CDROM, not Microfiche.

> There is now a port called 
> OpenVMS.

There was no "port" of VMS called OpenVMS.  OpenVMS is a marketing
term introduced about 1992 which was not indicative of any new coding
(except for changing the default banner displayed when you log in).

> As for the VMS version of Ada RTL written in Bliss, that 
> also proves my point of no "Ada only Run-Time System".

If by "no Ada only Run-Time system" you mean "no Run-Time system
written in Ada", you use a poor choice of word.

> An Alpha with GEM, well the Alpha was created in 1992. Not at the 
> birth of Ada. But again GEM means no "Ada only Run-Time System".

GEM is a code generator, not a run time library:

Directory SYS$COMMON:[SYSLIB]

ADARTL.EXE;1
DEC$BASRTL.EXE;1
DEC$COBRTL.EXE;1
DEC$FORRTL.EXE;2   
PAS$RTL.EXE;1


Total of 5 files.

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> That may be true for VMS but since the information that was certified 
> by the DOD said C for Ada. And that the final word, because the DOD 
> certified it was so.


Last time you were talking about the DOD you accused them of
falsifying history and suppressing information on the true coures of
events ...

- M

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> Showing your TROLLISM!
>
> If you check GNU GNAT 4.3 it contains 
> Ada.Numerics.Aux -- for Vxworks which link into GCC C libraies.
> Ada.Numerics.Aux -- for darwin also links to thier GCC C library.
> All Ada.Numerics.Aux use the C code.
>  
>
>   GET OVER IT! YOU CAN NEVER PROVE THAT GNAT DOES NOT 
>   INCLUDE LINK INTO THE GCC C LIBRARIES! AND THESE 
>   LIBRARY ROUTINES ARE LINKED INTO YOU CODE IF YOU 
>   NEED THOSE ROUTINES!
>
>
> AND AS FOR YOUR OTHER POST NO PROVE EITHER! MINE PAPERS AT 
> ACM.

Your caps key got stuck. Just in case you didn't notice. Regarding
proof: Just claiming "my papers are ACM" is a bit thin. I suggest you
back up your claims by putting proper references and quotes on the
table as behoves in a debate between historian. 

Until then everything _you_ say are unfounded claims -- and if they
are far enough away from what has been accepted lore so far and
accompanied by some clearly or at least very probably wrong claims,
nobody will ever bother to check the less easy to decide claims --
because one has to cull the decision tree at some point and given the
circumstances a low propability has been assigned to a success of the
strategy to look for new and revolutionary insights in your claims.

- M

Re: Ravenscar-compliant bounded buffer

[Pascal Obry]

anon a �crit :
> Showing your TROLLISM!

Isn't it the fourth or fifth time you called somebody a troll ? Just be
cause somebody does not share your opinion...

> If you check GNU GNAT 4.3 it contains
> Ada.Numerics.Aux -- for Vxworks which link into GCC C libraies.

Right.

> Ada.Numerics.Aux -- for darwin also links to thier GCC C library.

Right.

> All Ada.Numerics.Aux use the C code.

Nope, Gautier was right, the x86 version uses only Asm.

At this point your credibility is probably around 0 on this forum.

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: Ravenscar-compliant bounded buffer

[anon]

TROLL!

You can find this on the net. The second paragraph states that
GNAT uses GIGI routine to transform the  AST (Gnat internal trees) 
into an equivalent C tree. For figures do a search for the title and 
load the web page or pdf file.

There are others papers but this is getting borring ! 


Extract Title page and first two paragraphs from Chapter 1.3: 

 A Detailed Description of the GNU Ada Run Time 

 (Version 1.0)

 Integrated with the GNAT 3.15p sources and the Annotated Ada 
 Reference Manual (Technical Corrigendum 1)

 Copyright (c) Javier Miranda
 jmiranda@iuma.ulpgc.es

 Applied Microelectronics Reseach Institute
 University of Las Palmas de Gran Canaria
 Canary Islands

 Spain

 Permission is granted to copy, distribute and/or modify
 this document under the terms of the GNU Free Documentation
 License, Version 1.1 or any latter published by the Free
 Software Foundation.
 14th December 2002



 1.3 The Compiler

 The compiler is composed of two main parts: the front-end and the 
 back-end (cf. Figure 1.2). The front-end of the GNAT compiler is 
 thus written in Ada95. The back-end of the compiler is the back-end 
 of GCC proper, extended to meet the needs of Ada semantics 
 [SGC94, Section 3.1].


 The front-end comprises five phases (cf. Figure 1.3): lexical 
 analysis, syntactic analysis (parsing), semantic analysis, AST 
 expansion, and finally AST transformation into an equivalent C 
 tree (this stage is labeled GiGi (GNAT to GNU transformation). 
 These phases communicate by means of a rather compact Abstract 
 Syntax Tree (AST). The implementation details of the AST are 
 hidden by several procedural interfaces that provide access to 
 syntactic and semantic attributes. The layering of the system, 
 and the various levels of abstraction, are the obvious benefits 
 of writing in Ada, in what one might call ``proper'' Ada style. 
 It is worth mentioning that strictly speaking GNAT does not use 
 a symbol table. Rather, all semantic information concerning 
 program entities is stored in defining occurrences of these 
 entities directly in the AST [SGC94, Section 3.1]. 


In <46e3d16e_5@news.bluewin.ch>, Gautier <gautier@fakeaddress.nil> writes:
>anon:
>
>> 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. That can be printed as a C program. Also there 
>> are a few web sites with doctoral thesis that states this as well as 
>> a few papers at ACM. And ACM group will verify the information before 
>> accepting thesis paper and this is where I learn of it. The paper include 
>> a program that will print internal C as a compilable C source code 
>> file.
>
>You could write a program that outputs the tree as a compilable Ada source code, 
>couldn't you ?
>
>> Now since, the mid 1980's most compiler are FRONT_END compilers aka 
>> a language translator that converts the source language to the system's 
>> main language, normal for today that's C with the exception of TI which 
>> used Pascal.  Then the FRONT_END compiler calls a BACK_END compiler 
>> (for GNAT this is done by the compiler calling "gigi" (gnat-to-gcc)), 
>> which re-calls the gcc compiler for GNU system so that the internal C 
>> can be converted to a object module or assembly source file. 
>> {{ continue below }}
>
>Between the front-end and the back-end, a data tree is passed, not a C source 
>code. As discussed earlier, there is no intermediary C code - please re-read and 
>remember R. Dewar's explanation. As a mnemotechnic exercise, I cannot resist to 
>quote this from c.l.a. (~1998):
>
>"Repeat after me:  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
>  GNAT does NOT produce C code.  GNAT does NOT produce C code. GNAT does NOT 
>produce C code.  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
>GNAT does NOT produce C code.  GNAT does NOT produce C code.  GNAT does NOT 
>produce C code.  GNAT does NOT produce C code.  GNAT does NOT produce C code. 
>GNAT does NOT produce C code.
>There.  Feel better now? :-)
>"
>______________________________________________________________
>Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
>Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
>
>NB: For a direct answer, e-mail address on the Web site!

Re: Ravenscar-compliant bounded buffer

[anon]

MOVE ON TROLL, MOVE ON!
PROOF IS ACCREDITED WEB SITES SUCH AS ACM, IEEE, 
UNIVERSITY, OR SOFTWARE COMPANY. NOT 
SOME "wikipedia.org' THAT CAN BE ALTERED BY ALMOST 
ANYONE WHO VIST THE WEB PAGE!


In <ymr6l93r7p.fsf@hod.lan.m-e-leypold.de>, Markus E L writes:
>
>'anon AT anon DOT org (anon)' wrote:
>
>> WHERE IS YOU PROOF!!! If your going to call a person a liar then you 
>
>Oh noes, he's writing caps again.
>
><snipped a lot of strange stuff about GNAT using C as backend and DEC in the Ada history>
>
>> Before GNU system the idea of multi-platform compilers basically did 
>> not happen, but since then the major software houses have adopted this 
>> concept. A quick reason is that once they create a new processor they 
>
>See PCC, the portable C compiler by
>Johnson. E.g. http://en.wikipedia.org/wiki/Portable_C_Compiler for
>further references.
>
>Concerning your attempts to rewrite history concerning DEC and Ada: It
>might be that you'r basing your comments on a possible pre
>standardization involvment of DEC in the Ada development effort
>between 1979 and 1983 when "Green" was finally chosen to become
>Ada. Maybe DEC developed one of the Stoneman prototype
>compilers. Information about this is difficult to find w/o deeper
>research which I'm not in the mood to do now, and without you giving
>any references (which you really should, given that you try to tell a
>story that is different from what I know as accepted history). At the
>very least you're emphasizing the part of DEC in Ada history beyond
>all proportion (in another post some weeks ago you wrote something to
>the effect that DEC owns Ada - WTF?). But the thing that makes be
>really really suspicious is when you don't get thing right which (a) I
>know better and (b) you could have found out with a bit research, I
>even dare say: In some 10 years in the industry (and aren't you always
>pretending you're such an old hand?) you could not have been able to
>avoid learning some parts of the history, like about Johnson's
>portable compiler.
>
>So when everything is said and done, I begin to doubt especially the
>things in your statements which cannot be checked immediately. 
>
>And I would really appreciate if you stopped taking on a posture as an
>expert and talk like "ex cathedra". There are simply to many half
>truths and plain untruths in your grand sweeping oratories.
>
>> do not have to re-write all of the compiler codes and libraries. Just 
>> create the C compiler and recompile the software system from there.
>>
>
>
>-- Markus

Re: Ravenscar-compliant bounded buffer

[Pascal Obry]

anon a �crit :
> TROLL!

Again :)

> There are others papers but this is getting borring ! 

Because you just confuse C tree (or more precisely the GCC tree used by
Fortran, ObjectiveC, C, C++, Pascal, Ada...) and C source. This is not
our fault if you keep trying to avoid understand what others have been
saying in this tread!!! Please now stop this nonsense, thanks.

      GNAT code generation is not related to C in whatever manner.

And yes this is my last message to you as I really think I'm loosing my
time at this point.

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: Ravenscar-compliant bounded buffer

[anon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

I CALL THEM AS I SEE THEM!  TROLL. 

And for me I do not care what you think of my CREDIBILITY is, 
but since a lot of you have decided to fight, I think most that 
will read these post here would say your CREDIBILITY, is the 
one that is zero. Because at some point I give information that 
can be seen as legal proof. None of you have any true proof only 
state what you want to say. Just like this post, no proof, only 
your opinion! 

If you give useful information then you are helping.  But to arguing 
about English semantic and calling people lairs is a TROLL and ONLY 
a TROLL. Which this newgroups from the first time I made a post just 
proves that you are TROLLS. And every newgroups have 100s of TROLLS 
running around. As long as people agree with them they are quite but 
when someone question them or trys to make them THINK they ATTACK
in packs!!!!


ALSO DOES FIGHTING WITH ME ADD OR HURTS THIS NEWGROUP?




In <46E3FA9A.6090409@obry.net>, Pascal Obry <pascal@obry.net> writes:
>anon a �crit :
>> Showing your TROLLISM!
>
>Isn't it the fourth or fifth time you called somebody a troll ? Just be
>cause somebody does not share your opinion...
>
>> If you check GNU GNAT 4.3 it contains
>> Ada.Numerics.Aux -- for Vxworks which link into GCC C libraies.
>
>Right.
>
>> Ada.Numerics.Aux -- for darwin also links to thier GCC C library.
>
>Right.
>
>> All Ada.Numerics.Aux use the C code.
>
>Nope, Gautier was right, the x86 version uses only Asm.
>
>At this point your credibility is probably around 0 on this forum.

 NO PROOF, ONLY YOUR OPINION, TYPE OF ANSWER!

>
>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: Ravenscar-compliant bounded buffer

[Markus E L]

'Colossus DOT Pike AT worldnet DOT att DOT net (anon)' wrote:

<the following quote from some other paper:>

>  The compiler is composed of two main parts: the front-end and the 
>  back-end (cf. Figure 1.2). The front-end of the GNAT compiler is 
>  thus written in Ada95. The back-end of the compiler is the back-end 
>  of GCC proper, extended to meet the needs of Ada semantics 
>  [SGC94, Section 3.1].

<...>

>
>  The front-end comprises five phases (cf. Figure 1.3): lexical 
>  analysis, syntactic analysis (parsing), semantic analysis, AST 
>  expansion, and finally AST transformation into an equivalent C 
>  tree (this stage is labeled GiGi (GNAT to GNU transformation). 

>  These phases communicate by means of a rather compact Abstract 
>  Syntax Tree (AST). 

Reading seems to be an art you've only mastered incompletely so
far. Nowhere it says that GNAT produces C code (C tree is something
else).

- M

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> MOVE ON TROLL, MOVE ON!

Hm, are you the group's traffic police man or its "Blockwart"? Since
so far you've labeled around 6 people here as trolls (or should that
be TROLLS? Is the capsing important?), I doubt you're representing
c.l.a. in any way. So stop policing.

> PROOF IS ACCREDITED WEB SITES SUCH AS ACM, IEEE, 
> UNIVERSITY, OR SOFTWARE COMPANY. NOT 
> SOME "wikipedia.org' THAT CAN BE ALTERED BY ALMOST 
> ANYONE WHO VIST THE WEB PAGE!

You're still CAPSing.

You seem to have an incomplete understanding how the historical
sciences (and to a certain extent all sciences) work: By a certain
majority of researchers agreeing on what should from then on should be
considered established fact. To that end, historians participating in
the debate are required to quote sources on what they want to
establish as facts. None of the sources is proof, though, because
source might err, or might have been falsified in the past by
interested parties. Only by drawing on a number of various sources,
weighting them in their context (and by reputation) a complete picture
emerges and consensus can be reached.

Regarding Wikipedia: I haven't quoted that as as source, but rather as
a short and readable summary of what I consider to be established
history.

Regarding you attempts to "proof" something: As I said there are no
proofs regarding history. But you haven't even quoted sources. The
only thing I've seen so far are claims the "the ACM says so" or
something to the effect. Apart from the fact that the ACM review
process might also be incomplete (has been, indeed), that is not
enough: Please quote verse and chapter as any proper scientist should
do. Thank you. 

(And BTW: the ACM doesn't "check" the papers, as you said, at least
not in the sense a criminalist or exmperimental scientist does: They
are just peer reviewed and dependend on the reviewer single facts
might plainly be wrong (but not having fallen in the scope of
expertise of the reviewers) - so much about _single_ ACM papers as
source of historical truth. They are only sources.)

You yourself don't count as a source: Since your credibility factor
has approached negative values, you're rather an anti-source so far.

As a last comment (in this post): Wikipedia is nearer to the ideal of
a scientific process than your spoutings:

  - Wikipedia is reviewed, almost constantly in fact. :-)
  - Wikipedia very often quotes and references external sources.

On the other hand

  - You don't reference identifiable sources

  - You're the only one claiming a number of things so far and have
    been rebutted repeatedly.

So if I would have to decide: Whom should I rather believe, you, or
WP?  Guess ...

(Fortunately I have other choices like, e.g. starting with reading the
papers referenced by Micheal Feldmann in "The Handbook of Programming
languages").

-- Markus

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:
>
> ALSO DOES FIGHTING WITH ME ADD OR HURTS THIS NEWGROUP?

I think it improves this newsgroup, since it flags nonesense as
nonsense. Rather important for posteriority, considering that news
articles will stay for the rest of the century.

-- Markus

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> I CALL THEM AS I SEE THEM!  TROLL. 
>
> And for me I do not care what you think of my CREDIBILITY is, 
> but since a lot of you have decided to fight, I think most that 
> will read these post here would say your CREDIBILITY, is the 
> one that is zero. Because at some point I give information that 
> can be seen as legal proof. 

Legal proof? I must've missed that. How does it looke like in your
hands? Or do you propose that you're testifying as witness? If so, the
question of credibility creeps in ... -- uh oh.

- M

Re: Ravenscar-compliant bounded buffer

[Ed Falis]

On Sun, 09 Sep 2007 11:22:23 -0400, anon <anon@anon.org> wrote:

> I CALL THEM AS I SEE THEM!  TROLL.

In Buddhist scriptures, the convention for opening a lecture or story is  
something along the lines of "Bhikksus"!  (meaning "Disciples, students  
...".  We now have a new convention in the c.l.a scriptures, where the  
stories and lecture start with the honorific: "TROLL"!

Re: Ravenscar-compliant bounded buffer

[Markus E L]

"Ed Falis" wrote:

> On Sun, 09 Sep 2007 11:22:23 -0400, anon <anon@anon.org> wrote:
>
>> I CALL THEM AS I SEE THEM!  TROLL.
>
> In Buddhist scriptures, the convention for opening a lecture or story
> is  something along the lines of "Bhikksus"!  (meaning "Disciples,
> students  ...".  We now have a new convention in the c.l.a scriptures,
> where the  stories and lecture start with the honorific: "TROLL"!

Meaning: "You, who don't agree with me ...".

:-)

Regards -- Markus

Re: Ravenscar-compliant bounded buffer

[Niklas Holsti]

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
       .      @       .

Re: Ravenscar-compliant bounded buffer

[Ed Falis]

Oh Noble TROLL!

On Sun, 09 Sep 2007 15:12:51 -0400, Niklas Holsti  
<niklas.holsti@nospam.please> wrote:

A rather accurate description of what is really going on with GNAT.

- Ed

Re: Ravenscar-compliant bounded buffer

[Larry Kilgallen]

In article <42lkbfrfl3.fsf@hod.lan.m-e-leypold.de>, Markus E L writes:
> 
> 'anon AT anon DOT org (anon)' wrote:
>>
>> ALSO DOES FIGHTING WITH ME ADD OR HURTS THIS NEWGROUP?
> 
> I think it improves this newsgroup, since it flags nonesense as
> nonsense.

Oh, I think the All-Caps does that well enough.

Re: Ravenscar-compliant bounded buffer

[Markus E L]

'Kilgallen AT SpamCop DOT net (Larry Kilgallen)' wrote:

> In article <42lkbfrfl3.fsf@hod.lan.m-e-leypold.de>, Markus E L writes:
>> 
>> 'anon AT anon DOT org (anon)' wrote:
>>>
>>> ALSO DOES FIGHTING WITH ME ADD OR HURTS THIS NEWGROUP?
>> 
>> I think it improves this newsgroup, since it flags nonesense as
>> nonsense.
>
> Oh, I think the All-Caps does that well enough.

Quite right. But he starts capsing only after being contradicted, so
one needs to contradict a bit to get the self-flagging effect. :-).

Regards -- Markus

Re: Ravenscar-compliant bounded buffer

[Colin Paul Gloster]

On 2007-09-08, Nicholas Holsti <niklas.holsti@nospam.please> wrote:

|-------------------------------------------------------------------------|
|"[..]                                                                    |
|                                                                         |
|Then there is the Open Ravenscar Kernel ORK for GNAT,                    |
|http://polaris.dit.upm.es/~ork/, also written in Ada.                    |
|                                                                         |
|[..]"                                                                    |
|-------------------------------------------------------------------------|

Some of it was written in Ada, much of it was written in C and copied
from RTEMS.

Re: Ravenscar-compliant bounded buffer

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:DbqEi.507138$p47.352055@bgtnsc04-news.ops.worldnet.att.net...
...
> What I was trying to hint at without beating someone up about it was
> that the C code files should go.  Links to the Operating System and
> hardware drivers should be direct though use of the "Import pragma"
> not though a C interface driver file like GNAT and yes, and DEC
> still uses. And the C libraries need to be rewritten in Ada.

Many Ada compilers have little or no C in their runtime. There surely is
none in Janus/Ada (some assmbler, the rest is Ada), and my understanding is
that is also the case for several other compilers. But keep in mind that the
underlying OS (Windows for Janus/Ada) is probably written in C or something
even more error-prone. So what the Ada runtime is written in isn't likely to
have much effect on the reliability of the entire system.

We did once have a bare machine version of Janus/Ada (I know other companies
did too), but we dropped it for lack of demand. Almost every runs on some
sort of OS these days.

                              Randy.