* New GNAT ports (was Re: Ada and Automotive Industry) @ 1996-12-24 0:00 Robert Dewar 1996-12-27 0:00 ` New GNAT ports John Howard 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe 0 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1996-12-24 0:00 UTC (permalink / raw) obert Eachus says >" Amen! If it wasn't clear before, that was exactly my point. The >cost of the port can be academic if you can't guarantee that the >compiler will be ready in time. I'd want a lot of time for an 8051 >GNAT target, but for many other potential targets (especially if gcc >has already been ported) it is possible to get something up and >running in a week. You may spend the next several months getting it >thoughly wrung out and tested, getting the some of the annex support >working, building high-level bindings to OS specific libraries, etc., >but without much schedule risk involved. (In case that last part is >confusing, there are parts of the annexes that you can spend a lot of >time on if you care, for example Interfaces to COBOL, or tweaking the >numerics performance. But there shouldn't be any schedule risk early >in a project from that. Most of the GNAT annex code ports with the >compiler with no extra effort.)" I would amend that slightly to say "get something up and running in a week", if you do not include tasking. The tasking may be easy if you have a system that is very close to Posix compliant, but in our experience there are lots of variations in threads packages that complicate this task, and I would more comfortably restrict the "in a week" to exclude tasking. Also, this is assuming everything goes smoothly, and depends on the quality of the GCC port, and also how unusual the machine is. GNAT tends to excercise some aspects of a port which are not excercised by GNU C, and so you can find that a port needs more work than you thought. Still the bottom line is certainly that GNAT technology can be ported much more rapidly than other technologies which require a new code generator to be written. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports 1996-12-24 0:00 New GNAT ports (was Re: Ada and Automotive Industry) Robert Dewar @ 1996-12-27 0:00 ` John Howard 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe 1 sibling, 0 replies; 30+ messages in thread From: John Howard @ 1996-12-27 0:00 UTC (permalink / raw) On 24 Dec 1996, Robert Dewar wrote: > Still the bottom line is certainly that GNAT technology can be ported > much more rapidly than other technologies which require a new code > generator to be written. I saw in a recent SEIC Reuse announcement that ACT has a new GNAT compiler designed for targeting real-time embedded systems. It had a version number around 2.01 or so. Please provide any information you can about it. ------------------------------------------------------------------------ -- John Howard <jhoward@sky.net> -- Team Ada Team OS/2 -- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1996-12-24 0:00 New GNAT ports (was Re: Ada and Automotive Industry) Robert Dewar 1996-12-27 0:00 ` New GNAT ports John Howard @ 1997-01-07 0:00 ` Richard A. O'Keefe 1997-01-07 0:00 ` Ken Garlington ` (5 more replies) 1 sibling, 6 replies; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-07 0:00 UTC (permalink / raw) > >" Amen! If it wasn't clear before, that was exactly my point. The > >cost of the port can be academic if you can't guarantee that the > >compiler will be ready in time. I'd want a lot of time for an 8051 > >GNAT target, I've been studying the 8051 recently. I've convinced myself that with the aid of one more pragma [%] an Ada *subset* can straightforwardly do everything that assembler can do. (Given a machine with 4k of code ROM (and _maybe_ up to 64k of external RAM) and < 256 bytes of data RAM (and _maybe_ up to 64k of clumsily accessed external RAM) you clearly aren't going to bother with interfaces to COBOL or floating point (my estimate is that a good FP package would eat the entire ROM) and given the way the 8051 does subroutine calls it's probably going to be a good idea to ban recursion and so on. It would of course be possible to achieve assembly code efficiency using such an Ada subset, because with the aid of machine code inserts your "Ada" code could *be* "assembler" code. It would still be useful to do because of packages and such. Would there be any point in writing this up? I've had wistful thoughts about a possible product. Given that the two smart cards I've seen used 8051-like processors, and given the range of applications for smart cards and "postage stamp" computers (my word, the smart card chips are cheaper than the concrete blocks my office is made from; the possibilities for instrumentation are *awesome*) I suspect that the 8051 lookalikes still have some useful lifespan, and that there is a bigger market than one might think. Example: a lot of money hereabouts goes into gambling. How about hand-held bingo machines? Or hand-held pokies? What would happen if you had phone cards where you could gamble, and the winnings would be free calls and the losses would be dead cards? What about smart buildings with polymer-based chemical sensors hooked up to postage stamp computers communicating over twisted pairs that can *cheaply* monitor internal air pollutants? I mean, we're talking about systems where the wire would be the most expensive part! [%] The pragma is pragma Origin(non-negative constant integer expression); saying that the first byte of the textually following statement is to be at the given address. That was the only thing I saw in the 8051 book I was reading that I couldn't do in a reasonable Ada subset. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe @ 1997-01-07 0:00 ` Ken Garlington 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-07 0:00 ` Robert Dewar ` (4 subsequent siblings) 5 siblings, 1 reply; 30+ messages in thread From: Ken Garlington @ 1997-01-07 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > [%] The pragma is > pragma Origin(non-negative constant integer expression); > saying that the first byte of the textually following statement > is to be at the given address. That was the only thing I saw in > the 8051 book I was reading that I couldn't do in a reasonable > Ada subset. Couldn't this be handled via a combination of existing Ada support (address clauses, etc.) plus linker support? That's the way we usually handle it with the MIL-STD-1750. I don't know if you want to specify origins for random code; usually, it's for a logically related set of code/data/literals, or for a specific object. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` Ken Garlington @ 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Ken Garlington 0 siblings, 2 replies; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-08 0:00 UTC (permalink / raw) Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes: >Couldn't this be handled via a combination of existing Ada support >(address clauses, etc.) plus linker support? >I don't know if you want to specify origins for >random code; usually, it's for a logically related set of >code/data/literals, or for a specific object. The only reason that I bothered about the placement of code at all was that the 8051 book I was studying included a memory test program that did this. According to the Ada 83 LRM I had handy, you _couldn't_ supply address clauses for code. I suggested a pragma because it seemed to me that they were the _right_ way to add things like that; that specific pragma wouldn't change the meaning of the code, so could be stripped out for testing elsewhere. When you are trying to make a case that "language X can solve problem Y", opponents sometimes regard appeal to "linker support" as a copout. In the absence of an Ada-8051 compiler, if I had to write any microcontroller code, I'd use Prolog or Lisp as a macro assembler, and build a lot of error checking into it. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Richard A. O'Keefe @ 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-11 0:00 ` Addresses of Subprograms (was: New GNAT ports) Larry Kilgallen 1997-01-09 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Ken Garlington 1 sibling, 2 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) Richard said "The only reason that I bothered about the placement of code at all was that the 8051 book I was studying included a memory test program that did this. According to the Ada 83 LRM I had handy, you _couldn't_ supply address clauses for code." That is wrong, Ada 83 did allow you to specify the address of a subprogram, and in fact using this in conjunction with pragma Interface was a well known way of fooling a compiler into providing a mechanism equiavlent to an indirect call: procedure x; for x'address use expression; -- expression need not be static pragma interface (Ada, x); now when you call x, you call the subprogram at the given address. In fact CIFO specifically required this to work! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Robert Dewar @ 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` Addresses of Subprograms (was: New GNAT ports) Larry Kilgallen 1 sibling, 1 reply; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-09 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Richard said >"The only reason that I bothered about the placement of code at all >was that the 8051 book I was studying included a memory test program >that did this. According to the Ada 83 LRM I had handy, you _couldn't_ >supply address clauses for code." >That is wrong, Ada 83 did allow you to specify the address of a subprogram, No, it is not wrong. "code" is not a synonym of "subprogram". The memory test program in question had reason to scatter _parts_ of a subprogram around memory, and I appear to have got "Ada 83 didn't let you supply address clauses for code _other_ than the start of a subprogram" right. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-09 0:00 ` Richard A. O'Keefe @ 1997-01-11 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-11 0:00 UTC (permalink / raw) Richard said "No, it is not wrong. "code" is not a synonym of "subprogram". The memory test program in question had reason to scatter _parts_ of a subprogram around memory, and I appear to have got "Ada 83 didn't let you supply address clauses for code _other_ than the start of a subprogram" right." Well I still think it is wrong to try to do that at the source code level, I prefer the kind of approach Intel uses with a separate locator, i.e. you break the code into chunks, call them control sections or whatever, but they are named chunks, and then the locator places these named chunks at specified locations. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Addresses of Subprograms (was: New GNAT ports) 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe @ 1997-01-11 0:00 ` Larry Kilgallen 1997-01-13 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 30+ messages in thread From: Larry Kilgallen @ 1997-01-11 0:00 UTC (permalink / raw) In article <dewar.852774527@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Richard said > > "The only reason that I bothered about the placement of code at all > was that the 8051 book I was studying included a memory test program > that did this. According to the Ada 83 LRM I had handy, you _couldn't_ > supply address clauses for code." > > That is wrong, Ada 83 did allow you to specify the address of a subprogram, > and in fact using this in conjunction with pragma Interface was a well > known way of fooling a compiler into providing a mechanism equiavlent to > an indirect call: Was that a requirement ? The VAX Ada Version 2.0 manual I have from DEC shows a little pentagon-shaped logo saying "Validated Ada" in the middle and cites ANSI/MIL-STD 1815A as determined by the AJPO under its current testing procedures. But Section 13.5 after Paragraph 7 has vendor-specific (blue) text saying "In VAX Ada, the simple name must be the name of an object." Larry Kilgallen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Addresses of Subprograms (was: New GNAT ports) 1997-01-11 0:00 ` Addresses of Subprograms (was: New GNAT ports) Larry Kilgallen @ 1997-01-13 0:00 ` Larry Kilgallen 1997-01-14 0:00 ` Richard A. O'Keefe 1997-01-15 0:00 ` Richard Kenner 0 siblings, 2 replies; 30+ messages in thread From: Larry Kilgallen @ 1997-01-13 0:00 UTC (permalink / raw) In article <dewar.852774527@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Richard said > > "The only reason that I bothered about the placement of code at all > was that the 8051 book I was studying included a memory test program > that did this. According to the Ada 83 LRM I had handy, you _couldn't_ > supply address clauses for code." > > That is wrong, Ada 83 did allow you to specify the address of a subprogram, > and in fact using this in conjunction with pragma Interface was a well > known way of fooling a compiler into providing a mechanism equiavlent to > an indirect call: These two uses for specifying the address of code (memory test vs. indirect call) would seem to conflict in the case of Alpha VMS where the "procedure value" commonly passed as the "address" of a subprogram is quite different from the address of the first instruction of the subprogram executable code. I am curious regarding the approach ACT is taking in this regard. The need for fooling the compiler goes away in Ada95, and the use of a different mechanism in DEC Ada means code migrating from there would not depend on that trick for indirect calls. Macintosh 68K images depend heavily on a "jump table" where once again the "address" of a routine is quite a different thing from the location of its code (and, in fact, the location of the code might not be resolved until call time). Do other operating systems have this separation, and which is the "true" meaning for specifying the address of a subprogram from an Ada perspective ? Larry Kilgallen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Addresses of Subprograms (was: New GNAT ports) 1997-01-13 0:00 ` Larry Kilgallen @ 1997-01-14 0:00 ` Richard A. O'Keefe 1997-01-14 0:00 ` Fergus Henderson 1997-01-15 0:00 ` Richard Kenner 1 sibling, 1 reply; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-14 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: [There is a distinction between the "address" of a subprogram, meaning "what do I use for an indirect call" and the "address" of a subprogram, meaning "where does the executable code start". He cites the Alpha VMS and Macintosh 68k environments as examples, and asks ] >Do other operating systems have this separation, and which is the >"true" meaning for specifying the address of a subprogram from an >Ada perspective ? The Apollo systems did this too. I never used Aegis, but the UNIX systems they shipped had C function pointers being pointers to indirect blocks, the actual code being elsewhere. It was actually a pain for us (Quintus) because we wanted to put a certain procedure at a particular address (so we could use 16-bit addresses on a 68k) and you could never expect a procedure to be in the same place twice running. Lisp systems have often done this (the "slow link" / "fast link" distinction) in order to support run-time redefinition of procedures. What do the Ada->J-code compilers do? -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Addresses of Subprograms (was: New GNAT ports) 1997-01-14 0:00 ` Richard A. O'Keefe @ 1997-01-14 0:00 ` Fergus Henderson 0 siblings, 0 replies; 30+ messages in thread From: Fergus Henderson @ 1997-01-14 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) summarizes kilgallen@eisner.decus.org (Larry Kilgallen)'s query: >[There is a distinction between the "address" of a subprogram, > meaning "what do I use for an indirect call" > and the "address" of a subprogram, > meaning "where does the executable code start". > He cites the Alpha VMS and Macintosh 68k environments as examples, > and asks >] >>Do other operating systems have this separation, and which is the >>"true" meaning for specifying the address of a subprogram from an >>Ada perspective ? I think RS/6000 systems running AIX also have this distinction. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Addresses of Subprograms (was: New GNAT ports) 1997-01-13 0:00 ` Larry Kilgallen 1997-01-14 0:00 ` Richard A. O'Keefe @ 1997-01-15 0:00 ` Richard Kenner 1 sibling, 0 replies; 30+ messages in thread From: Richard Kenner @ 1997-01-15 0:00 UTC (permalink / raw) In article <1997Jan13.102240.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: >These two uses for specifying the address of code (memory test vs. >indirect call) would seem to conflict in the case of Alpha VMS >where the "procedure value" commonly passed as the "address" >of a subprogram is quite different from the address of the first >instruction of the subprogram executable code. This is also the case on most ABIs for the RS/6000 and PowerPC. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Robert Dewar @ 1997-01-09 0:00 ` Ken Garlington 1 sibling, 0 replies; 30+ messages in thread From: Ken Garlington @ 1997-01-09 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes: > >Couldn't this be handled via a combination of existing Ada support > >(address clauses, etc.) plus linker support? > >I don't know if you want to specify origins for > >random code; usually, it's for a logically related set of > >code/data/literals, or for a specific object. > > The only reason that I bothered about the placement of code at all > was that the 8051 book I was studying included a memory test program > that did this. According to the Ada 83 LRM I had handy, you _couldn't_ > supply address clauses for code. As Dr. Dewar has already responded, you can (and we have) done this in Ada 83. In general, ROM tests can be done in Ada 83 (and in Ada 95, with the ability to manipulate addresses, it can be done _portably_ ;) Usually, rather than attempting to place the Ada objects to be tested at certain areas, we perform address manipulations to scan a given area of memory, where the regions are specified as constants not related to the placement of Ada objects. _RAM_ tests, on the other hand, are a little interesting in Ada (and a lot of other high-order languages). Consider, for example, a non-destructive RAM test involving writing a value to RAM, reading the value back, and making sure they match. A typical algorithm is to break RAM into blocks of a particular size, reserve one block for the RAM test, and then do the following: Test(Reserved_Block); for Block_Index in All_Blocks loop Reserved_Block := RAM_Block(Block_Index); Test(RAM_Block(Block_Index)); RAM_Block(Block_Index) := Reserved_Block; end loop; What gets interesting is that the stack and heap are going to be destroyed as a part of this procedure. If Test tries to access the stack/heap while it's overwritten... bad business! Perhaps pragma (Local_Values_in_Registers_Only) would help? :) Usually, we write such a routine in assembly. Since it's such a small part of the total system, the maintenance impacts are negligible. > I suggested a pragma because it seemed > to me that they were the _right_ way to add things like that; that > specific pragma wouldn't change the meaning of the code, so could be > stripped out for testing elsewhere. When you are trying to make a > case that "language X can solve problem Y", opponents sometimes > regard appeal to "linker support" as a copout. Realistically, however, there are always some low-level operations that will require linker support, regardless of the language, for any language which allows the compilation of components at different times. So, I would say that someone who makes such an objection isn't going to be swayed by any reasonable argument. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe 1997-01-07 0:00 ` Ken Garlington @ 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Ken Garlington 1997-01-07 0:00 ` Robert A Duff ` (3 subsequent siblings) 5 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-07 0:00 UTC (permalink / raw) Richard suggests: [%] The pragma is pragma Origin(non-negative constant integer expression); saying that the first byte of the textually following statement is to be at the given address. That was the only thing I saw in the 8051 book I was reading that I couldn't do in a reasonable Ada subset. Well if we added this pragma, it is clear the argument should be of type address, but in any case the pragma is redundant. The proper diction is: for label'address use expression and then you simply label the statement It actually makes more conceptual sense to me to put a subprogram at a particular address, rather than a statement, in which case you can use for subprogram'address use expression which is more familiar (and more likely to be supported out of the box, although GNAT suports neither diction currently). ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` Robert Dewar @ 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Robert Dewar 1997-01-08 0:00 ` Ken Garlington 1 sibling, 1 reply; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-08 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >[%] The pragma is > pragma Origin(non-negative constant integer expression); >Well if we added this pragma, it is clear the argument should be of >type address, but in any case the pragma is redundant. The proper >diction is: > for label'address use expression >and then you simply label the statement Ah. I didn't know you could do that. Where do you put it? Can you provide an example? >It actually makes more conceptual sense to me to put a subprogram >at a particular address, rather than a statement, in which case you >can use > for subprogram'address use expression >which is more familiar (and more likely to be supported out of the box, >although GNAT suports neither diction currently). I agree, but remember, the question was not "what is more sense", or "what is more familiar", or "what is more likely to be supported out of the box" (the last because we're talking about a hypothetical _new_ compiler which _would_ support it). The question was "is there anything you can do in 8051 assembler [as shown by the examples in such-and-such an 8051 book] that cannot be done, and done well, in Ada?" Providing an address clause for a label is indeed a _much_ better way to do it. I note that AI-00336/05-ra-WJ says that "An address clause cannot be given for a subprogram whose body acts as its declaration." which I take to mean that a subprogram can have a normal body or an address clause but not both. A fortiori, I didn't expect address clauses to work for labels either. It certainly wasn't legal syntax in Ada 83, according to LRM 13.5. There is actually one more problem with the 8051, which is that there are three kinds of addresses: - 16-bit instruction addresses - 16-bit external RAM addresses - 8-bit internal RAM addressse However, this one _can_ be fixed using existing mechanisms: type Byte is mod 2**8; type Internal_Byte_Ptr is access Byte; for Internal_Byte_Ptr'Size use 8; type External_Byte_Ptr is access Byte; for External_Byte_Ptr'Size use 16; X: aliased Byte; for X'Address use System.R0'Address; -- in Internal RAM PX: Internal_Byte_Ptr := X'Access; Y: aliased Byte; for Y'Address use System.Address'(External_RAM, 257); PY: External_Byte_Ptr := Y'Access; : with System.Address being a suitable variant record type. This really shows off why Ada is better suited to this kind of thing than C. So the net conclusion is that you can obtain a good language for 8051 programming by starting with Ada 95 and - adding for Label'Address use System.Address'(ROM, nnnnn); and/or allowing for Subprogram'Address use System'Address(ROM, nnnn); when a body is also provided. - enforcing restrictions. The set of restrictions in pragma Restrictions is implementation defined, so 8051-specific things like pragma Restrictions(No_Float); would be ok. - filling in the machine code facilities of the language suitably. Does anyone else share my pleased surprise that so little is needed? -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Richard A. O'Keefe @ 1997-01-08 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) Richard says "I note that AI-00336/05-ra-WJ says that "An address clause cannot be given for a subprogram whose body acts as its declaration." which I take to mean that a subprogram can have a normal body or an address clause but not both. A fortiori, I didn't expect address clauses to work for labels either. It certainly wasn't legal syntax in Ada 83, according to LRM 13.5." You are confused, the quoted sentence simly says that if you have an address clause for a subprogram, it must have a separate spec. The conclusion you draw does not follow. As for address on labels, in Ada 83, you could not specify the value of attributes in general, but in Ada 95 you can with an attribute definition clause. Since Address clearly aplies to labels: 11 X'Address Denotes the address of the first of the storage elements allocated to X. For a program unit or label, this value refers to the machine code associated with the corresponding body or statement. The value of this attribute is of type System.Address. This certainly means that an implementation *may* support the address clause for a label. The only requirement (well it is a requirement if Annex C is supported) is: 17 An implementation should support Address clauses for imported subprograms. So, you are not required to support address clauses for non-imported subprograms, but in an embedded environment, it may well make sense to support this. Although it should be noted that an alternative mechanism to expressing this kind of thing at the language level is to use what Intel would call a locator to place code at specific locations in the final load image. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe @ 1997-01-08 0:00 ` Ken Garlington 1 sibling, 0 replies; 30+ messages in thread From: Ken Garlington @ 1997-01-08 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Richard suggests: > > [%] The pragma is > pragma Origin(non-negative constant integer expression); > saying that the first byte of the textually following statement > is to be at the given address. That was the only thing I saw in > the 8051 book I was reading that I couldn't do in a reasonable > Ada subset. > > Well if we added this pragma, it is clear the argument should be of > type address, but in any case the pragma is redundant. The proper > diction is: > > for label'address use expression > > and then you simply label the statement > > It actually makes more conceptual sense to me to put a subprogram > at a particular address, rather than a statement, in which case you > can use > > for subprogram'address use expression > > which is more familiar (and more likely to be supported out of the box, > although GNAT suports neither diction currently). I think you would also want to be able to control the placement of code, and literal sections of a subprogram (and, for packages, static data) indepedently, but that's easily done via linker commands in many systems. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe 1997-01-07 0:00 ` Ken Garlington 1997-01-07 0:00 ` Robert Dewar @ 1997-01-07 0:00 ` Robert A Duff 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Karl Cooper ` (2 subsequent siblings) 5 siblings, 2 replies; 30+ messages in thread From: Robert A Duff @ 1997-01-07 0:00 UTC (permalink / raw) In article <5asvku$jtu$1@goanna.cs.rmit.edu.au>, Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote: >I've been studying the 8051 recently. >I've convinced myself that with the aid of one more pragma [%] >an Ada *subset* can straightforwardly do everything that assembler >can do. How would this subset compare to the Ada subset embedded in SPARK? >...I mean, we're talking >about systems where the wire would be the most expensive part! Then why bother using a high-level language at all? I mean, if the software is small and cheap enough, then assembly works fine. - Bob ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` Robert A Duff @ 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-07 0:00 UTC (permalink / raw) Robert Duff asks (about a possible 8051 subset) How would this subset compare to the Ada subset embedded in SPARK? not comparable at all. The SPARK subset is not only aimed at reducing runtime complexity, but also at reducing certification effort. If you are interested in reducing runtime costs, then you are concerned with things that have code generation impact (for instance, floating-point might be out of the question, but generic instantiation and child packages are irrelevant). But if you are interested in certification, then floating-point may be fine if you can find an acceptable formal model for floating-point, but you may well decide to eliminate generics and child units on the grounds that the complicate the formal models without providing any fudnamental increase in expressive power. By fudnamental here, I mean that you can always do generics yourself if you have to for example, ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` Robert A Duff 1997-01-07 0:00 ` Robert Dewar @ 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-09 0:00 ` Dr. Peter E. Obermayer 1 sibling, 1 reply; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-08 0:00 UTC (permalink / raw) >Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote: >I've been studying the 8051 recently. >I've convinced myself that ... an Ada *subset* can straightforwardly >do everything that assembler can do. bobduff@world.std.com (Robert A Duff) writes: >How would this subset compare to the Ada subset embedded in SPARK? I haven't yet found out what the SPARK subset is. I believe SPARK omits exception handling, and it's not clear to me that you need to do that. With enough external ROM (often EPROM) I think you can afford the tables and code to do it. But it would obviously be useful to exploit pragma Restrictions. >>...I mean, we're talking >>about systems where the wire would be the most expensive part! >Then why bother using a high-level language at all? I mean, if the >software is small and cheap enough, then assembly works fine. There is a serious non-sequitur there. The wire would be the most expensive *hardware* part (cheaper than the CPU chips). That in no way implies that the software would be cheap. Using a high level language is often a good way to make the software *cheaper*. Then there is the distinction between _cost_ and _risk_. A lot of people got sucked into becoming "names" at Lloyd's; the _cost_ of doing that was nowhere near as high as the _risk_, which turned out to be catastrophic liability for asbestos claims for the foreseeable future. Even if using a high level language didn't reduce the _immediate_ cost of the software, if it helped make it easier to get it _right_, it could dramatically reduce subsequent liability costs. Suppose, for example, that there _were_ an Ada-8051 compiler that did a reasonable job, and that you wrote a program in assembler, and it didn't quite work, and you got sued; would you like it if the plaintiff's expert said in court that there was a programming language around that _could_ have been used which would have detected the error? There've been a couple of occasions when I was asked to act as an expert witness. None of them came to court, but I promise you, I was ready with a listing of 'lint' output... A modern smart card may have, oh, 16k of code and 32k of EPROM, and may run complicated encryption and/or compression algorithms. Why _not_ develop this code on a workstation with a good environment first, and then bind it to the card chip later? Bear in mind also that there are a couple of families of microcontroller chips. I've been thinking about the 8051 family, but it's a large family with some odd members. There _are_ potentially reusable components (drivers for peripherals; security handshakes; compression code; ...) that _might_ be more reusable in Ada+representation glue than in assembler. And think about the things that a compiler can do for you. The subroutine call stack on the 8051 is very limited. A compiler can - enforce a pragma Restrictions(No_Recursion); - expand in-line any subprogram that _happens_ to be called in only one place - check that the final call graph does not exceed the usable depth - perhaps even use some other calling mechanism for some subprograms When memory is so very tight, it would be nice to _know_ that you weren't going to run out. I am _not_ saying that developing an Ada-8051 compiler would be _easy_, only that there appear to be no _technical_ barriers, only economic and marketing ones. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Richard A. O'Keefe @ 1997-01-09 0:00 ` Dr. Peter E. Obermayer 0 siblings, 0 replies; 30+ messages in thread From: Dr. Peter E. Obermayer @ 1997-01-09 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > >Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote: > >I've been studying the 8051 recently. > >I've convinced myself that ... an Ada *subset* can straightforwardly > >do everything that assembler can do. > > bobduff@world.std.com (Robert A Duff) writes: > >How would this subset compare to the Ada subset embedded in SPARK? > > I haven't yet found out what the SPARK subset is. Look at http://www.praxis.co.uk/technols/spark/sp_lang.htm#rationale ... lots of other things deleted > > -- > My tertiary education cost a quarter of a million in lost income > (assuming close-to-minimum wage); why make students pay even more? > Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. -- _/_/_/ _/_/_/ _/_/_/ Dr. Peter E. Obermayer _/ _/ _/ Tel.: (05931) 805-163 _/ _/ _/ Lohberg 10 Fax: (05931) 842-163 _/_/_/ _/_/_/ _/_/_/ D-49716 Meppen E-Mail: obermayer@cci.de ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe ` (2 preceding siblings ...) 1997-01-07 0:00 ` Robert A Duff @ 1997-01-08 0:00 ` Karl Cooper 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-09 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robert I. Eachus 5 siblings, 2 replies; 30+ messages in thread From: Karl Cooper @ 1997-01-08 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > I've been studying the 8051 recently. > I've convinced myself that with the aid of one more pragma [%] > an Ada *subset* can straightforwardly do everything that assembler > can do. snip > Would there be any point in writing this up? > I've had wistful thoughts about a possible product. We are deeply involved in a commercial product which depends heavily on an 8051 derivative. Over ten thousand lines of C code are being maintained at the heart of this product. Reliability and maintain- ability issues have been raised. Migrating the software to GNAT- for-the-8051 might be a wise move for us. Keep the group posted as to progress. Karl Cooper contractor with Additional Tech Nashua, NH ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Karl Cooper @ 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) Karl wrote: "We are deeply involved in a commercial product which depends heavily on an 8051 derivative. Over ten thousand lines of C code are being maintained at the heart of this product. Reliability and maintain- ability issues have been raised. Migrating the software to GNAT- for-the-8051 might be a wise move for us. Keep the group posted as to progress." Just so no false hopes are raised here. The discussion so far has been solely on feasibility. That I know of, no one is working on actually doing a GNAT port. I do not even know if there is a gcc port, let alone a good one, which is a prerequisite before even thinking about a GNAT port. Soi ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-08 0:00 ` Karl Cooper 1997-01-08 0:00 ` Robert Dewar @ 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-09 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-09 0:00 UTC (permalink / raw) I have recently been arguing that an Ada-8501 would be doable. Karl Cooper <"X0723$"@mailgw.sanders.lockheed.com> writes: >We are deeply involved in a commercial product which depends heavily >on an 8051 derivative. Over ten thousand lines of C code are being >maintained at the heart of this product. Reliability and maintain- >ability issues have been raised. Migrating the software to GNAT- >for-the-8051 might be a wise move for us. Keep the group posted >as to progress. I do hope I haven't misled anyone. "wistful thoughts about a product" doesn't mean "concrete plans". I *do* think it is doable. I *would* be interested in doing it. However, it's not the thing that I could reasonably do on my own in my spare time. There *are* some students talking to me about doing a compiler project, but their previous experience consists of having read the Dragon book. (That's _good_ experience, but not enough, I think.) I've poked around in the GNAT sources from time to time, but have never studied the whole thing. People who _have_ studied it: how long do you think it would take to understand the GNAT front end well enough to make an informed judgement about the difficulty of writing a non-GCC back end for it? As I see it, the main problems in a project to actually _do_ this include - making an informed judgement about whether the thing is possible in principle [done] - making an informed judgement about whether doing it by writing a new back end for GNAT (and adding some more Restrictions) [doable with present resources, save possibly time] - finishing the design of the pragmas, System additions, and machine code form. - producing some sample programs in Ada-8051 to arouse even more interest (say translating everything in the book I mentioned before) [a tiny bit done] - putting together a plan (even if it's people donating time, like the Linux project, how _many_ people? doing what exactly?) - getting together a group of volunteers - making the necessary changes to the front end - building a back end (possibly adapting one from a free C-8051 to start with) - integrating and testing, which needs a preceding step of - producing test programs (new code + hand translated "real" code) ... In the mean time, there's a statistics language which needs a compiler, and I think that _is_ within the capabilities of the students and myself, so unless someone offers me startup finance to do Ada-8051, I'd be doing the other instead. I guess that's the point: the only barrier to Ada-8051 is _money_, not technical issues. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-09 0:00 ` Richard A. O'Keefe @ 1997-01-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-01-09 0:00 UTC (permalink / raw) Richard said "I've poked around in the GNAT sources from time to time, but have never studied the whole thing. People who _have_ studied it: how long do you think it would take to understand the GNAT front end well enough to make an informed judgement about the difficulty of writing a non-GCC back end for it?" The front end of GNAT is pretty accessible. Read the documentation in sinfo and einfo to get a definition of the tree that is produced. Writing a production quality backend for any machine from scratch is a big project, of the order of person years for someone who knows what they are doing. Adapting an existing backend (if one is available that can be GPL'ed) is certainly a possibility, although sometimes clashes in assumptions can make such a project harder than expected. Note that the Ada Magic front end is more deliberately setup to provide for interfacing with multiple backends (this is obviously not a criterion for GNAT, since the assumption is that only one backend, GCC, will be used). Certainly building a small trial code generator hooked into the backend of GNAT is practical. I am planning on having my students in my compiler class do that this coming semester. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe ` (3 preceding siblings ...) 1997-01-08 0:00 ` Karl Cooper @ 1997-01-09 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robert I. Eachus 5 siblings, 0 replies; 30+ messages in thread From: Robert I. Eachus @ 1997-01-09 0:00 UTC (permalink / raw) In article <5avdtl$hir$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: > I note that AI-00336/05-ra-WJ says that > "An address clause cannot be given for a subprogram > whose body acts as its declaration." > which I take to mean that a subprogram can have a normal body or > an address clause but not both.... Don't get confused by the RM-speak. All this says is that if you want to have such an address clause, the specification to which it applies must be explicit. In other works: procedure Foo; for Foo'Address use Some_Address; ... procedure body Foo is.... The address clause has to appear after the declaration but before the body, and that is difficult if they are the same unit. (It is also difficult to do right for generic instantiations.) But, as far as I can tell that is an Ada 83 rule only. In Ada 95, an implementation is allowed to--but not required to--support an address clause for an implicitly defined procedure. (But don't hold your breath.) Note also that the addresses are not required by the language to be static. However, a compiler can put in such a restriction. (The sensible choice for an implementation would seem to be to support all address clauses that can be resolved at link-time.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe ` (4 preceding siblings ...) 1997-01-09 0:00 ` Robert I. Eachus @ 1997-01-10 0:00 ` Robert I. Eachus 1997-01-11 0:00 ` Robert Dewar 5 siblings, 1 reply; 30+ messages in thread From: Robert I. Eachus @ 1997-01-10 0:00 UTC (permalink / raw) In article <dewar.852814793@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Writing a production quality backend for any machine from scratch is > a big project, of the order of person years for someone who knows what > they are doing. Adapting an existing backend (if one is available that > can be GPL'ed) is certainly a possibility, although sometimes clashes > in assumptions can make such a project harder than expected. For the 8051, starting with an the a version of gcc for the Intel 8086, 80186, 80286, or even the Z-80 should be a good start. But a gcc version that targets are 386 or higher is probably a waste of effort as a starting point. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-10 0:00 ` Robert I. Eachus @ 1997-01-11 0:00 ` Robert Dewar 1997-01-13 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-01-11 0:00 UTC (permalink / raw) Robert Eachus says " For the 8051, starting with an the a version of gcc for the Intel 8086, 80186, 80286, or even the Z-80 should be a good start. But a gcc version that targets are 386 or higher is probably a waste of effort as a starting point." This is a little confused. There is only one version of GCC, which is common across all targets. What specializes GCC to a particular target is the machine description file, which is essentially a formal description of the semantics of the target architecture. I don't see that the MD file for the 8086 would be a particularly helpful starting point for the 8051, except perhaps as a general indication of how MD files are written, although if you are not already thoroughly familiar with the mechanics of writing MD files for GCC, then you would be unlikely to succeed anyway with the 8051, which as has often been discussed here, is not an easy machine to target. Now it is also the case that if you tried to do an efficient GCC port to the 8051, you might well need to make some improvements in GCC, that's a steady process, and often driven by requirements that are initially generated by targetting to new architectures. The general idea here is not to put in special kludges for particular architectures (there is almost no specialization of this kind in GCC), but rather to abstract the general features involved, and provide enhancements that will be useful to any targets sharing the particular features involved. So it is quite likely that the 8051 might suggest some general improvements of this type, but there again, I doubt the 8086 would be a useful comparison point. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: New GNAT ports (was Re: Ada and Automotive Industry) 1997-01-11 0:00 ` Robert Dewar @ 1997-01-13 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 30+ messages in thread From: Richard A. O'Keefe @ 1997-01-13 0:00 UTC (permalink / raw) >Robert Eachus says >" For the 8051, starting with an the a version of gcc for the Intel >8086, 80186, 80286, or even the Z-80 should be a good start. The 8086 and the 8051 aren't all that much alike. The 8086 is a 16 bit machine, extended with segments. The 8051 is an 8 bit machine, without segments. For example, suppose we have something like type R is record x: Byte end; RV: R; and want to do RV.x := RV.x + 1; Assuming that the address of RV is known at link time, we can do inc RV'Address + 1 in the 8086. In the 8051, it's load DPTR with (RV'Address + 1) ld A, @DPTR inc A st A, @DPTR All external RAM references have to share a single 16-bit address register, and the set of operations on that register is rather restricted. (For example, to add something to DPTR, you must operate on its separate halves using 8-bit instructions.) In particular, the major reason why I would expect to use a pragma No_Recursion for Ada-8051 is not that it _can't_ be done (it can) but that it would seriously complicate the use of DPTR. One reason why I would expect Ada-8051 code to be easier to write than 8051 assembler is simply that the compiler would be able to keep track of the contents of DPTR more reliably than I can, and that it could schedule things in interesting ways to reduce DPTR reloads. Another difference is the fact that the 8086 has 16-bit and 32-bit pointers, both of which can point to the same memory locations, while the 8051 has 8-bit and 16-bit pointers, that canNOT point to the same memory locations. The thing that makes something like this practical, in my view, is that the goal is NOT to optimise arbitrary Ada code, but simply to do a reasonable job with code written specifically for the 8051. My claim is not that the 8051 is a good machine for Ada (which it clearly is NOT) but that an Ada SUBSET is a good language for the 8051. I believe that starting from a code generator for right machine (but wrong compiler front end) would be better than starting from a code generator for the wrong machine (but write compiler front end), since converting between intermediate representations (which GNAT already does) just takes compile time, while code generation affects the final code. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1997-01-15 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-12-24 0:00 New GNAT ports (was Re: Ada and Automotive Industry) Robert Dewar 1996-12-27 0:00 ` New GNAT ports John Howard 1997-01-07 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe 1997-01-07 0:00 ` Ken Garlington 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` Addresses of Subprograms (was: New GNAT ports) Larry Kilgallen 1997-01-13 0:00 ` Larry Kilgallen 1997-01-14 0:00 ` Richard A. O'Keefe 1997-01-14 0:00 ` Fergus Henderson 1997-01-15 0:00 ` Richard Kenner 1997-01-09 0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Ken Garlington 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-08 0:00 ` Robert Dewar 1997-01-08 0:00 ` Ken Garlington 1997-01-07 0:00 ` Robert A Duff 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Richard A. O'Keefe 1997-01-09 0:00 ` Dr. Peter E. Obermayer 1997-01-08 0:00 ` Karl Cooper 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Richard A. O'Keefe 1997-01-09 0:00 ` Robert Dewar 1997-01-09 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robert I. Eachus 1997-01-11 0:00 ` Robert Dewar 1997-01-13 0:00 ` Richard A. O'Keefe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox