From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c30642befcd7bf85 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: New GNAT ports (was Re: Ada and Automotive Industry) Date: 1997/01/08 Message-ID: <5avdtl$hir$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 208616606 references: <5asvku$jtu$1@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1997-01-08T00:00:00+00:00 List-Id: 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.