* Ravenscar-compliant bounded buffer @ 2007-09-04 13:53 Maciej Sobczak 2007-09-05 3:00 ` Steve 0 siblings, 1 reply; 49+ messages in thread From: Maciej Sobczak @ 2007-09-04 13:53 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-04 13:53 Ravenscar-compliant bounded buffer Maciej Sobczak @ 2007-09-05 3:00 ` Steve 2007-09-05 7:38 ` Maciej Sobczak 2007-09-05 7:46 ` Dmitry A. Kazakov 0 siblings, 2 replies; 49+ messages in thread From: Steve @ 2007-09-05 3:00 UTC (permalink / raw) 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/ > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-05 3:00 ` Steve @ 2007-09-05 7:38 ` Maciej Sobczak 2007-09-06 4:04 ` Steve 2007-09-05 7:46 ` Dmitry A. Kazakov 1 sibling, 1 reply; 49+ messages in thread From: Maciej Sobczak @ 2007-09-05 7:38 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-05 7:38 ` Maciej Sobczak @ 2007-09-06 4:04 ` Steve 2007-09-06 14:06 ` Robert A Duff 0 siblings, 1 reply; 49+ messages in thread From: Steve @ 2007-09-06 4:04 UTC (permalink / raw) "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/ > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 4:04 ` Steve @ 2007-09-06 14:06 ` Robert A Duff 2007-09-06 15:36 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Robert A Duff @ 2007-09-06 14:06 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 14:06 ` Robert A Duff @ 2007-09-06 15:36 ` Dmitry A. Kazakov 2007-09-07 2:36 ` Robert A Duff 2007-09-06 21:13 ` Maciej Sobczak 2007-09-07 1:38 ` Steve 2 siblings, 1 reply; 49+ messages in thread From: Dmitry A. Kazakov @ 2007-09-06 15:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 15:36 ` Dmitry A. Kazakov @ 2007-09-07 2:36 ` Robert A Duff 0 siblings, 0 replies; 49+ messages in thread From: Robert A Duff @ 2007-09-07 2:36 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 14:06 ` Robert A Duff 2007-09-06 15:36 ` Dmitry A. Kazakov @ 2007-09-06 21:13 ` Maciej Sobczak 2007-09-07 2:41 ` Robert A Duff 2007-09-07 11:56 ` anon 2007-09-07 1:38 ` Steve 2 siblings, 2 replies; 49+ messages in thread From: Maciej Sobczak @ 2007-09-06 21:13 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 21:13 ` Maciej Sobczak @ 2007-09-07 2:41 ` Robert A Duff 2007-09-07 11:56 ` anon 1 sibling, 0 replies; 49+ messages in thread From: Robert A Duff @ 2007-09-07 2:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 21:13 ` Maciej Sobczak 2007-09-07 2:41 ` Robert A Duff @ 2007-09-07 11:56 ` anon 2007-09-07 19:44 ` Maciej Sobczak 1 sibling, 1 reply; 49+ messages in thread From: anon @ 2007-09-07 11:56 UTC (permalink / raw) >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/ > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-07 11:56 ` anon @ 2007-09-07 19:44 ` Maciej Sobczak 2007-09-08 0:16 ` anon 0 siblings, 1 reply; 49+ messages in thread From: Maciej Sobczak @ 2007-09-07 19:44 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-07 19:44 ` Maciej Sobczak @ 2007-09-08 0:16 ` anon 2007-09-08 1:19 ` Larry Kilgallen 2007-09-08 11:50 ` Niklas Holsti 0 siblings, 2 replies; 49+ messages in thread From: anon @ 2007-09-08 0:16 UTC (permalink / raw) 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/ > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 0:16 ` anon @ 2007-09-08 1:19 ` Larry Kilgallen 2007-09-08 5:13 ` anon 2007-09-08 11:50 ` Niklas Holsti 1 sibling, 1 reply; 49+ messages in thread From: Larry Kilgallen @ 2007-09-08 1:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 1:19 ` Larry Kilgallen @ 2007-09-08 5:13 ` anon 2007-09-08 22:06 ` Larry Kilgallen 2007-09-11 2:44 ` Randy Brukardt 0 siblings, 2 replies; 49+ messages in thread From: anon @ 2007-09-08 5:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 5:13 ` anon @ 2007-09-08 22:06 ` Larry Kilgallen 2007-09-09 2:17 ` anon 2007-09-11 2:44 ` Randy Brukardt 1 sibling, 1 reply; 49+ messages in thread From: Larry Kilgallen @ 2007-09-08 22:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 22:06 ` Larry Kilgallen @ 2007-09-09 2:17 ` anon 2007-09-09 12:07 ` Larry Kilgallen 2007-09-09 13:10 ` Markus E L 0 siblings, 2 replies; 49+ messages in thread From: anon @ 2007-09-09 2:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 2:17 ` anon @ 2007-09-09 12:07 ` Larry Kilgallen 2007-09-09 13:10 ` Markus E L 1 sibling, 0 replies; 49+ messages in thread From: Larry Kilgallen @ 2007-09-09 12:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 2:17 ` anon 2007-09-09 12:07 ` Larry Kilgallen @ 2007-09-09 13:10 ` Markus E L 1 sibling, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 13:10 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 5:13 ` anon 2007-09-08 22:06 ` Larry Kilgallen @ 2007-09-11 2:44 ` Randy Brukardt 1 sibling, 0 replies; 49+ messages in thread From: Randy Brukardt @ 2007-09-11 2:44 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 0:16 ` anon 2007-09-08 1:19 ` Larry Kilgallen @ 2007-09-08 11:50 ` Niklas Holsti 2007-09-08 12:01 ` Pascal Obry ` (2 more replies) 1 sibling, 3 replies; 49+ messages in thread From: Niklas Holsti @ 2007-09-08 11:50 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 11:50 ` Niklas Holsti @ 2007-09-08 12:01 ` Pascal Obry 2007-09-08 17:13 ` anon 2007-09-08 17:11 ` anon 2007-09-10 12:51 ` Colin Paul Gloster 2 siblings, 1 reply; 49+ messages in thread From: Pascal Obry @ 2007-09-08 12:01 UTC (permalink / raw) To: Niklas Holsti 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 12:01 ` Pascal Obry @ 2007-09-08 17:13 ` anon 0 siblings, 0 replies; 49+ messages in thread From: anon @ 2007-09-08 17:13 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 11:50 ` Niklas Holsti 2007-09-08 12:01 ` Pascal Obry @ 2007-09-08 17:11 ` anon 2007-09-08 19:14 ` Markus E L ` (3 more replies) 2007-09-10 12:51 ` Colin Paul Gloster 2 siblings, 4 replies; 49+ messages in thread From: anon @ 2007-09-08 17:11 UTC (permalink / raw) 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 > . @ . ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 17:11 ` anon @ 2007-09-08 19:14 ` Markus E L 2007-09-09 14:54 ` anon 2007-09-09 10:38 ` Gautier ` (2 subsequent siblings) 3 siblings, 1 reply; 49+ messages in thread From: Markus E L @ 2007-09-08 19:14 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 19:14 ` Markus E L @ 2007-09-09 14:54 ` anon 2007-09-09 16:01 ` Markus E L 0 siblings, 1 reply; 49+ messages in thread From: anon @ 2007-09-09 14:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 14:54 ` anon @ 2007-09-09 16:01 ` Markus E L 0 siblings, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 16:01 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 17:11 ` anon 2007-09-08 19:14 ` Markus E L @ 2007-09-09 10:38 ` Gautier 2007-09-09 11:41 ` anon 2007-09-09 10:57 ` Gautier 2007-09-09 19:12 ` Niklas Holsti 3 siblings, 1 reply; 49+ messages in thread From: Gautier @ 2007-09-09 10:38 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 10:38 ` Gautier @ 2007-09-09 11:41 ` anon 2007-09-09 13:19 ` Markus E L 2007-09-09 13:52 ` Pascal Obry 0 siblings, 2 replies; 49+ messages in thread From: anon @ 2007-09-09 11:41 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 11:41 ` anon @ 2007-09-09 13:19 ` Markus E L 2007-09-09 13:52 ` Pascal Obry 1 sibling, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 13:19 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 11:41 ` anon 2007-09-09 13:19 ` Markus E L @ 2007-09-09 13:52 ` Pascal Obry 2007-09-09 15:22 ` anon 1 sibling, 1 reply; 49+ messages in thread From: Pascal Obry @ 2007-09-09 13:52 UTC (permalink / raw) To: anon 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 13:52 ` Pascal Obry @ 2007-09-09 15:22 ` anon 2007-09-09 16:03 ` Markus E L ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: anon @ 2007-09-09 15:22 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 15:22 ` anon @ 2007-09-09 16:03 ` Markus E L 2007-09-10 0:05 ` Larry Kilgallen 2007-09-09 16:05 ` Markus E L 2007-09-09 18:40 ` Ed Falis 2 siblings, 1 reply; 49+ messages in thread From: Markus E L @ 2007-09-09 16:03 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 16:03 ` Markus E L @ 2007-09-10 0:05 ` Larry Kilgallen 2007-09-10 3:10 ` Markus E L 0 siblings, 1 reply; 49+ messages in thread From: Larry Kilgallen @ 2007-09-10 0:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-10 0:05 ` Larry Kilgallen @ 2007-09-10 3:10 ` Markus E L 0 siblings, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-10 3:10 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 15:22 ` anon 2007-09-09 16:03 ` Markus E L @ 2007-09-09 16:05 ` Markus E L 2007-09-09 18:40 ` Ed Falis 2 siblings, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 16:05 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 15:22 ` anon 2007-09-09 16:03 ` Markus E L 2007-09-09 16:05 ` Markus E L @ 2007-09-09 18:40 ` Ed Falis 2007-09-09 19:11 ` Markus E L 2 siblings, 1 reply; 49+ messages in thread From: Ed Falis @ 2007-09-09 18:40 UTC (permalink / raw) 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"! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 18:40 ` Ed Falis @ 2007-09-09 19:11 ` Markus E L 0 siblings, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 19:11 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 17:11 ` anon 2007-09-08 19:14 ` Markus E L 2007-09-09 10:38 ` Gautier @ 2007-09-09 10:57 ` Gautier 2007-09-09 14:49 ` anon 2007-09-09 19:12 ` Niklas Holsti 3 siblings, 1 reply; 49+ messages in thread From: Gautier @ 2007-09-09 10:57 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 10:57 ` Gautier @ 2007-09-09 14:49 ` anon 2007-09-09 15:08 ` Pascal Obry 2007-09-09 15:38 ` Markus E L 0 siblings, 2 replies; 49+ messages in thread From: anon @ 2007-09-09 14:49 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 14:49 ` anon @ 2007-09-09 15:08 ` Pascal Obry 2007-09-09 15:38 ` Markus E L 1 sibling, 0 replies; 49+ messages in thread From: Pascal Obry @ 2007-09-09 15:08 UTC (permalink / raw) To: anon 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 14:49 ` anon 2007-09-09 15:08 ` Pascal Obry @ 2007-09-09 15:38 ` Markus E L 1 sibling, 0 replies; 49+ messages in thread From: Markus E L @ 2007-09-09 15:38 UTC (permalink / raw) '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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 17:11 ` anon ` (2 preceding siblings ...) 2007-09-09 10:57 ` Gautier @ 2007-09-09 19:12 ` Niklas Holsti 2007-09-09 19:28 ` Ed Falis 3 siblings, 1 reply; 49+ messages in thread From: Niklas Holsti @ 2007-09-09 19:12 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-09 19:12 ` Niklas Holsti @ 2007-09-09 19:28 ` Ed Falis 0 siblings, 0 replies; 49+ messages in thread From: Ed Falis @ 2007-09-09 19:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-08 11:50 ` Niklas Holsti 2007-09-08 12:01 ` Pascal Obry 2007-09-08 17:11 ` anon @ 2007-09-10 12:51 ` Colin Paul Gloster 2 siblings, 0 replies; 49+ messages in thread From: Colin Paul Gloster @ 2007-09-10 12:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-06 14:06 ` Robert A Duff 2007-09-06 15:36 ` Dmitry A. Kazakov 2007-09-06 21:13 ` Maciej Sobczak @ 2007-09-07 1:38 ` Steve 2007-09-07 2:47 ` Robert A Duff 2 siblings, 1 reply; 49+ messages in thread From: Steve @ 2007-09-07 1:38 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-07 1:38 ` Steve @ 2007-09-07 2:47 ` Robert A Duff 0 siblings, 0 replies; 49+ messages in thread From: Robert A Duff @ 2007-09-07 2:47 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-05 3:00 ` Steve 2007-09-05 7:38 ` Maciej Sobczak @ 2007-09-05 7:46 ` Dmitry A. Kazakov 2007-09-05 8:17 ` brodax 2007-09-05 8:30 ` Jean-Pierre Rosen 1 sibling, 2 replies; 49+ messages in thread From: Dmitry A. Kazakov @ 2007-09-05 7:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-05 7:46 ` Dmitry A. Kazakov @ 2007-09-05 8:17 ` brodax 2007-09-05 8:30 ` Jean-Pierre Rosen 1 sibling, 0 replies; 49+ messages in thread From: brodax @ 2007-09-05 8:17 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Ravenscar-compliant bounded buffer 2007-09-05 7:46 ` Dmitry A. Kazakov 2007-09-05 8:17 ` brodax @ 2007-09-05 8:30 ` Jean-Pierre Rosen 1 sibling, 0 replies; 49+ messages in thread From: Jean-Pierre Rosen @ 2007-09-05 8:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2007-09-11 2:44 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-04 13:53 Ravenscar-compliant bounded buffer Maciej Sobczak 2007-09-05 3:00 ` Steve 2007-09-05 7:38 ` Maciej Sobczak 2007-09-06 4:04 ` Steve 2007-09-06 14:06 ` Robert A Duff 2007-09-06 15:36 ` Dmitry A. Kazakov 2007-09-07 2:36 ` Robert A Duff 2007-09-06 21:13 ` Maciej Sobczak 2007-09-07 2:41 ` Robert A Duff 2007-09-07 11:56 ` anon 2007-09-07 19:44 ` Maciej Sobczak 2007-09-08 0:16 ` anon 2007-09-08 1:19 ` Larry Kilgallen 2007-09-08 5:13 ` anon 2007-09-08 22:06 ` Larry Kilgallen 2007-09-09 2:17 ` anon 2007-09-09 12:07 ` Larry Kilgallen 2007-09-09 13:10 ` Markus E L 2007-09-11 2:44 ` Randy Brukardt 2007-09-08 11:50 ` Niklas Holsti 2007-09-08 12:01 ` Pascal Obry 2007-09-08 17:13 ` anon 2007-09-08 17:11 ` anon 2007-09-08 19:14 ` Markus E L 2007-09-09 14:54 ` anon 2007-09-09 16:01 ` Markus E L 2007-09-09 10:38 ` Gautier 2007-09-09 11:41 ` anon 2007-09-09 13:19 ` Markus E L 2007-09-09 13:52 ` Pascal Obry 2007-09-09 15:22 ` anon 2007-09-09 16:03 ` Markus E L 2007-09-10 0:05 ` Larry Kilgallen 2007-09-10 3:10 ` Markus E L 2007-09-09 16:05 ` Markus E L 2007-09-09 18:40 ` Ed Falis 2007-09-09 19:11 ` Markus E L 2007-09-09 10:57 ` Gautier 2007-09-09 14:49 ` anon 2007-09-09 15:08 ` Pascal Obry 2007-09-09 15:38 ` Markus E L 2007-09-09 19:12 ` Niklas Holsti 2007-09-09 19:28 ` Ed Falis 2007-09-10 12:51 ` Colin Paul Gloster 2007-09-07 1:38 ` Steve 2007-09-07 2:47 ` Robert A Duff 2007-09-05 7:46 ` Dmitry A. Kazakov 2007-09-05 8:17 ` brodax 2007-09-05 8:30 ` Jean-Pierre Rosen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox