* Rep specs @ 1999-05-31 0:00 Eddy Raineri 1999-05-31 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Eddy Raineri @ 1999-05-31 0:00 UTC (permalink / raw) Hello, I have a question regarding rep specs. There is an individual I work with that has stated that rep specs are not required by the LRM and as I qoute "DO NOT USE ADA REP SPECS except in the simplest of cases, or unless you are sure that the code will NEVER be ported to a different machine or compiler (hah!)" I had a totally different opinion. So I have the following questions. 1) I was under the impression that it was. It is in chapter 13 and not an annex. Is it required? 2) I was also thought that using rep specs is ideal for dealing with porting issues and cross platform communications. I.E. if a 32 bit PC was talking to an 8 bit microcontroller via a serial line. Is this correct? 3) I also thought that by using rep specs you may not be optimizing the code correctly for the platform but you are assuring that it will port correctly to another compiler/platform without any heartburn. 4) I also beleived that using pragm pack and rep spec will allow you to correctly access hardware registers correctly without using complex bit manipulation techniques or extra code. Thanks in advance for you help E. Raineri ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-05-31 0:00 Rep specs Eddy Raineri @ 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` czgrr 1999-06-03 0:00 ` Marin David Condic 1999-06-01 0:00 ` Steve Quinlan 1999-06-03 0:00 ` Samuel T. Harris 2 siblings, 2 replies; 11+ messages in thread From: Robert Dewar @ 1999-05-31 0:00 UTC (permalink / raw) In article <tqx43.5040$xF2.70329@news1.rdc2.tx.home.com>, "Eddy Raineri" <eraineri@axiom-tx.com> wrote: > Hello, > I have a question regarding rep specs. There is an individual I work with > that has stated that rep specs are not required by the LRM and as I qoute > "DO NOT USE ADA REP SPECS except in the simplest of cases, or unless you are > sure that the code will NEVER be ported to a different machine or compiler > (hah!)" > Rep specs (more properly rep clauses) are not required unless you implement the Systems Programming Annex. That makes sense. For the type of thing that needs rep clauses, that annex had better be implemented. In fact virtually all compilers support this on virtually all machines. An exception might be a compiler targetting the JVM, where systems programming is not really practical in any case. However, the "individual you work with" is QUITE wrong in reocmmending against using rep clauses completely. As you point out in your examples, careful use of rep clauses (as well as address attributes etc) can greatly AID in portability. Forbidding these features may very well cause you to have to resort to low level do-it-your-self stuff which will be much less likely to be portable. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-05-31 0:00 ` Robert Dewar @ 1999-06-01 0:00 ` czgrr 1999-06-03 0:00 ` Marin David Condic 1 sibling, 0 replies; 11+ messages in thread From: czgrr @ 1999-06-01 0:00 UTC (permalink / raw) In article <7iuqvu$lpp$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <tqx43.5040$xF2.70329@news1.rdc2.tx.home.com>, > "Eddy Raineri" <eraineri@axiom-tx.com> wrote: > > Hello, > > I have a question regarding rep specs. There is an individual > I work with > > that has stated that rep specs are not required by the LRM and > as I qoute > > "DO NOT USE ADA REP SPECS except in the simplest of cases, or > unless you are > > sure that the code will NEVER be ported to a different machine > or compiler > > (hah!)" > > > > However, the "individual you work with" is QUITE wrong in > reocmmending against using rep clauses completely. As you > point out in your examples, careful use of rep clauses (as > well as address attributes etc) can greatly AID in portability. > Forbidding these features may very well cause you to have to > resort to low level do-it-your-self stuff which will be much > less likely to be portable. > As an example of this, I ported (in Ada 83, BTW) a real time simulator from a UNIX VADS compiler to Windows 95-based ActivAda. It communicated with a GUI written in Visual C++ using formatted LAN messages. Now, in this case, using 'SIZE to specify the length of scalar types was very important because there were differences between the two compilers/machines that would have misaligned the message formats after the port. Using 'SIZE meant that there was no change. The messages would also have been messed up had we not used the occasional USE clause for a record, in the few cases where the C++ record was larger than the Ada record, and hence the Ada record needed 'padding'. Personally, though, I don't like them. Also, representation clauses were used to specify what values all enumerals should have because we did have some (not many, I grant you) which were not 0, 1, 2, etc. Most were not necessary, since both Ada and C++ defaults to 0, 1, 2, etc, but they were put in anyway "to make sure" as it is much easier to check against C++ if a problem arose. So I agree that it is wrong to ban representation clauses completely, since they most definitely eased the transition process and were actually necessary in several cases. I also have to say that I do believe that their use should be limited to where they *are* necessary, quite apart from the maintenance nightmare when one has over 100 layered records and a low-level record is changed! Cheers, czgrr -- No email, please - reply to the newsgroup. Email may be made public. My opinions are not necessarily those of my employer. My suggestions might not be correct. Use at your own risk. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` czgrr @ 1999-06-03 0:00 ` Marin David Condic 1 sibling, 0 replies; 11+ messages in thread From: Marin David Condic @ 1999-06-03 0:00 UTC (permalink / raw) Robert Dewar wrote: > Rep specs (more properly rep clauses) are not required unless > you implement the Systems Programming Annex. That makes sense. > For the type of thing that needs rep clauses, that annex had > better be implemented. In fact virtually all compilers support > this on virtually all machines. An exception might be a compiler > targetting the JVM, where systems programming is not really > practical in any case. > O.K. Now you've got me confused. Chapter 13 clearly defines syntax for representation clauses, but allows for interpretation in an implementation defined manner. That would seem to "require" support for representation clauses, even if the level of support is questionable. I'd imagine the compiler would be required to parse the clause and at least say something to the effect of "I know you asked for this, but I can't give it to you, so you get this other thing instead..." At least you are warned that the representation is not possible with the given implementation. (I'd agree that a compiler which refused to comply with all rep clauses no matter how trivial, would be behaving rather silly, but isn't that still some form of support?) I'd agree that the issue is rather one of hair splitting and mostly irrelavent since representation clauses are generally fully supported. But wouldn't the issue arise again for things such as pragmas? "Yes I recognize your pragma, but no, I'm not going to do anything about it" is a valid form of support. Or am I wrong on this score? MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.flipag.net/mcondic ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-05-31 0:00 Rep specs Eddy Raineri 1999-05-31 0:00 ` Robert Dewar @ 1999-06-01 0:00 ` Steve Quinlan 1999-06-02 0:00 ` Robert Dewar 1999-06-03 0:00 ` Samuel T. Harris 2 siblings, 1 reply; 11+ messages in thread From: Steve Quinlan @ 1999-06-01 0:00 UTC (permalink / raw) Read section 13 carefully. There are lots of vendor weasel words in there. "Recommended level of support", "an implementation may place implementation-defined restrictions on representation items", the "implementation advice" sections. All this means that representation clause support can vary significantly from one vendor to another. That doesn't mean "never use it", it means use it with your eyes open, be aware of the implementation dependent aspects of it. Also it matters WHY you are using it. There are a number of different things you might want to accomplish here. Determine which features of ch 13 you need, and determine with current and potential future compiler vendors what their level of support is for those features. They are supposed to document any restrictions they impose, advice they don't follow, etc. If you can't find the information in their documentation, then ask them. For example, with record representation clauses, maybe you are trying to achieve common data representation between different vendors (assuming things like endian-ness and FP format don't get in the way). Maybe you only want to assure a common representation from release to release of a single compiler (they are allowed to change the default lay out of data unless told otherwise by a rep clause). Maybe you want to match some register format or external data layout. If you're a big enough customer, the vendor(s) can be persuaded (and paid) to do things more to your liking (e.g., remove a restriction that they put in just for their convenience, but which you need removed), follow some implementation advice which they chose not to, etc. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-06-01 0:00 ` Steve Quinlan @ 1999-06-02 0:00 ` Robert Dewar 0 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1999-06-02 0:00 UTC (permalink / raw) In article <37542022.789354FD@nospam.lmco.com>, Steve Quinlan <steven.quinlan@nospam.lmco.com> wrote: > Read section 13 carefully. There are lots of vendor weasel > words in there. > "Recommended level of support", "an implementation may place > implementation-defined restrictions on representation items", > the > "implementation advice" sections. All this means that > representation clause > support can vary significantly from one vendor to another. That's over-pessimistic. All the sections in chapter 13 under recommended level of support become REQUIREMENTS for a compiler implementing the systems programming annex. Clearly if you want to use rep clauses, you should choose a compiler that supports this annex (virtually all compilers do), and then, if possible restrict your use of rep clauses to those that are included in these sections on recommended level of support. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-05-31 0:00 Rep specs Eddy Raineri 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` Steve Quinlan @ 1999-06-03 0:00 ` Samuel T. Harris 1999-06-04 0:00 ` Robert Dewar 2 siblings, 1 reply; 11+ messages in thread From: Samuel T. Harris @ 1999-06-03 0:00 UTC (permalink / raw) Eddy Raineri wrote: > > Hello, > I have a question regarding rep specs. There is an individual I work with > that has stated that rep specs are not required by the LRM and as I qoute > "DO NOT USE ADA REP SPECS except in the simplest of cases, or unless you are > sure that the code will NEVER be ported to a different machine or compiler > (hah!)" > > I had a totally different opinion. So I have the following questions. > > 1) I was under the impression that it was. It is in chapter 13 and not an > annex. Is it required? > 2) I was also thought that using rep specs is ideal for dealing with > porting issues and cross platform communications. I.E. if a 32 bit PC was > talking to an 8 bit microcontroller via a serial line. Is this correct? > 3) I also thought that by using rep specs you may not be optimizing the > code correctly for the platform but you are assuring that it will port > correctly to another compiler/platform without any heartburn. > 4) I also beleived that using pragm pack and rep spec will allow you to > correctly access hardware registers correctly without using complex bit > manipulation techniques or extra code. > > Thanks in advance for you help > E. Raineri In my experiences interfacing to hardware, as well as other languages, representation clauses are vital and mandatory in these situations. Therefore, their support becomes requirements for the target compiler/platform. If you have to force the layout of a record to conform to the storage layout of a memory mapped hardware device, then you must have the appropriate representation clause. Any compiler which does not support it is simply not a viable candidate target compiler. When supporting a new platform, compiler selection must satisfy your requirements and if you need representation clauses then they are in your requirements. Except for the earliest Ada 83 compilers, I have not run into significant issues with missing Chapter 13 features from 1985 to the present. That does not preclude the necessity of identifying these needs as requirements and verifying candidate compilers satisfy these needs. So I have rarely eliminated a candidate compiler from consideration due to limitation in their Chapter 13 support. Along this line, I've found that the new pragma convention in Ada 95 has made nearly all my code supporting interfacing with other languages obsolete. It is very convenient. And the systems programming annex does a very nice job of encapsulating the requirements of this problem domain. When considering Ada 83 compilers, I used to have a laundry list of Chapter 13 features which are required. With Ada 95, I simply need say "fully implements the systems programming annex" and I sleep well knowing my bases are covered. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep specs 1999-06-03 0:00 ` Samuel T. Harris @ 1999-06-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1999-06-04 0:00 UTC (permalink / raw) In article <3756CA64.A9EF5BA3@hso.link.com>, "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > With Ada 95, > I simply need say "fully implements the systems programming > annex" and I sleep well knowing my bases are covered. > > -- > Samuel T. Harris, Principal Engineer > Raytheon, Scientific and Technical Systems > "If you can make it, We can fake it!" Hmmm! In practice we find that very few large customers can live with the small subset of rep clauses required to be implemented by the systems programming annex, and a lot of our development work has been to add capabilities in this area, in response to customer requirements. Some examples: 1. Tight packing for other than 1,2,4,8 bits 2. Size clauses on records and arrays 3. Integer fields across storage boundaries 4. Arrays indexed by enumeration types with holes are compact 5. Record fields on other than natural alignment boundary There are many others. None of these are required by the SPA. Sam, are you really sure you stick strictly to the SPA subset? If so, you are, in our experience an unusual user. As I say, most of our users, especially those with legacy Ada 83 code, require far more. Indeed I would argue that the Ada 83 RM *required* a lot more, since it required the compiler to accept much more. In Ada 83, the only allowed restriction was: An implementation may limit its acceptance of representation clauses to those that can be handled simply by the underlying hardware. Now of course this is vague, since simply is not defined. On the other hand, it is clear that all the Ada 95 SPA requirements are indeed in this category. It is also clear that many things meet this requirement which are NOT required by the Ada 95 SPA. So in that sense, the requirements, while being more precise, are actually weaker. And if you think that is just a theoretical issue, consider that all major Ada 83 compilers went far beyond the current Ada 95 requirements in practice. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Rep Specs @ 1996-10-07 0:00 Doug Shipler 1996-10-08 0:00 ` Stephen Leake 0 siblings, 1 reply; 11+ messages in thread From: Doug Shipler @ 1996-10-07 0:00 UTC (permalink / raw) I am using SunAda83 version 1.1k on a SunOS Sparc 5. I have a record that is rep speced into 32 bit long words. One of the words is split up into several fields, one is a 16 bit integer, and the others are bit flags. The interesting part is that when I try to access one of the bit flags, the compiler fetches the wrong bit, it gets a bit from the 16 bit integer field. In this example, Flag3 accesses a bit inside Value. for My_Record_Typ use record at mod 32; Value at 0 * 4 range 16 .. 31; Flag1 at 0 * 4 range 15 .. 15; Flag2 at 0 * 4 range 13 .. 14; Unused1 at 0 * 4 range 10 .. 12; Flag3 at 0 * 4 range 9 .. 9; Flag4 at 0 * 4 range 8 .. 8; Unused2 at 0 * 4 range 4 .. 7; OtherVal at 0 * 4 range 0 .. 3; ........ Any ideas are greatly appreciated! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep Specs 1996-10-07 0:00 Rep Specs Doug Shipler @ 1996-10-08 0:00 ` Stephen Leake 1996-10-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 11+ messages in thread From: Stephen Leake @ 1996-10-08 0:00 UTC (permalink / raw) Doug Shipler wrote: > > I am using SunAda83 version 1.1k on a SunOS Sparc 5. I have a record > that is rep speced into 32 bit long words. One of the words is > split up into several fields, one is a 16 bit integer, and the > others are bit flags. The interesting part is that when I try to > access one of the bit flags, the compiler fetches the wrong bit, it > gets a bit from the 16 bit integer field. > > In this example, Flag3 accesses a bit inside Value. > > for My_Record_Typ use > record at mod 32; > Value at 0 * 4 range 16 .. 31; > Flag1 at 0 * 4 range 15 .. 15; > Flag2 at 0 * 4 range 13 .. 14; > Unused1 at 0 * 4 range 10 .. 12; > Flag3 at 0 * 4 range 9 .. 9; > Flag4 at 0 * 4 range 8 .. 8; > Unused2 at 0 * 4 range 4 .. 7; > OtherVal at 0 * 4 range 0 .. 3; > ........ > > Any ideas are greatly appreciated! I ran into a similar problem. The cause is that the Sparc is little-bit-endian; it stores the least significant bit in the highest numbered bit slot. This is how I solved the problem in a (so far) portable way: ------------ for Intel/gnat --------------- with System; package Endianness -- Purpose: -- define constants to reflect hardware bit and word endianness in -- record representation clauses (in Ada83). Obviously, this file is -- highly system-dependent (Ada95 solves this much more nicely!). is -- this is for gnat on an Intel 386 compatible processor System_Name : System.NAME := System.SYSTEM_NAME_GNAT; Bit_Order : constant := 1; High_Bit_First : constant := 1; Low_Bit_First : constant := 0; MSBit : constant := 7; LSBit : constant := 0; type Byte_Order_Type is (BIG_ENDIAN, LITTLE_ENDIAN); Byte_Order : constant Byte_Order_Type := LITTLE_ENDIAN; end Endianness; ------------------- for Sparc/SunAda -------------------- with System; package Endianness -- Purpose: -- define constants to reflect hardware bit and word endianness in -- record representation clauses (in Ada83). Obviously, this file is -- highly system-dependent (Ada95 solves this much more nicely!). is -- this is for Sun (Verdix) Ada on a Sparc processor System_Name : System.NAME := System.SUN4_UNIX; Bit_Order : constant := -1; High_Bit_First : constant := 0; Low_Bit_First : constant := 1; MSBit : constant := 0; LSBit : constant := 7; type Byte_Order_Type is (BIG_ENDIAN, LITTLE_ENDIAN); Byte_Order : constant Byte_Order_Type := BIG_ENDIAN; end Endianness; Then, a rep clause looks like: type Out_Health_Flags_Type is record User_Ephemeris_Needed : BOOLEAN; Approximate_GPS_Time_Needed : BOOLEAN; Self_Survey_Data_Needed : BOOLEAN; Almanac_Not_Current : BOOLEAN; Operational_Status : OPERATIONAL_STATUS_TYPE; end record; for Out_Health_Flags_Type use record User_Ephemeris_Needed at 0 range LSBit + Bit_Order * 0 .. LSBit + Bit_Order * 0; Approximate_GPS_Time_Needed at 0 range LSBit + Bit_Order * 1 .. LSBit + Bit_Order * 1; Self_Survey_Data_Needed at 0 range LSBit + Bit_Order * 2 .. LSBit + Bit_Order * 2; Almanac_Not_Current at 0 range LSBit + Bit_Order * 3 .. LSBit + Bit_Order * 3; Operational_Status at 0 range High_Bit_First * (LSBit + Bit_Order * 4) + Low_Bit_First * (LSBit + Bit_Order * 7) .. Low_Bit_First * (LSBit + Bit_Order * 4) + High_Bit_First * (LSBit + Bit_Order * 7); end record; for Out_Health_Flags_Type'Size use 8; As long as you include the proper version of Endianness in your library, the rep clause is correct for either little-bit-endian (Sparc) or big-bit-endian (Intel). Note that the issue of byte-endianness doesn't show up in the rep clause; that's handled by the `at 0', as long as Storage_Unit is 8 bits. Byte-endianness shows up when converting multi-byte values to byte arrays: function To_2_Byte is new Unchecked_Conversion (TARGET => Byte_Array_2_Type, SOURCE => Geode_Types.INTEGER); procedure To_Network (Item : in Geode_Types.INTEGER; Buffer : out Geode_Types.BYTE_ARRAY; Last : in out Geode_Types.INTEGER) is use Geode_Types; begin case Byte_Order is when BIG_ENDIAN => Buffer (Last+1 .. Last+2) := To_2_Byte (Item); when LITTLE_ENDIAN => declare Temp : constant BYTE_ARRAY (1 .. 2) := To_2_Byte (Item); begin Buffer (Last+1) := Temp (2); Buffer (Last+2) := Temp (1); end; end case; Last := Last+2; end To_Network; You MUST test this code for each compiler/hardware combination; some may do the integer <> byte array unchecked conversion differently. -- - Stephe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Rep Specs 1996-10-08 0:00 ` Stephen Leake @ 1996-10-13 0:00 ` Robert Dewar 0 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1996-10-13 0:00 UTC (permalink / raw) Stephen Lake said, responding to Doug Shipler's problem: "I ran into a similar problem. The cause is that the Sparc is little-bit-endian; it stores the least significant bit in the highest numbered bit slot." and then follows a very contorted work around! No, that's not the cause. The quoted code is quite correct, and should work on either a little endian or big-endian machine. If it does not you have run into a compiler bug. Your suggestion might be reasonable as a work around, but we should not leave the impression that this work around is neccessary on a correctly functioning Ada compiler! ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-06-04 0:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-31 0:00 Rep specs Eddy Raineri 1999-05-31 0:00 ` Robert Dewar 1999-06-01 0:00 ` czgrr 1999-06-03 0:00 ` Marin David Condic 1999-06-01 0:00 ` Steve Quinlan 1999-06-02 0:00 ` Robert Dewar 1999-06-03 0:00 ` Samuel T. Harris 1999-06-04 0:00 ` Robert Dewar -- strict thread matches above, loose matches on Subject: below -- 1996-10-07 0:00 Rep Specs Doug Shipler 1996-10-08 0:00 ` Stephen Leake 1996-10-13 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox