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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38ceb882eed41e1e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-27 18:30:35 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Size and pack Date: 27 Oct 2001 18:30:34 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0110271730.24d0b81e@posting.google.com> References: <9ff447f2.0110100005.2503bb00@posting.google.com> <9ff447f2.0110102224.5c470e2c@posting.google.com> <3bc55ea1.3939494@news.demon.co.uk> <3BC59C8E.BADA210D@Raytheon.com> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1004232634 7189 127.0.0.1 (28 Oct 2001 01:30:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 28 Oct 2001 01:30:34 GMT Xref: archiver1.google.com comp.lang.ada:15304 Date: 2001-10-28T01:30:34+00:00 List-Id: Mark Johnson wrote in message news:<3BC59C8E.BADA210D@Raytheon.com>... > Since Bit_Order is described in Chapter 13, all compilers > should support it. That's faulty reasoning. Let's look at the RM, it says that the recommended level of support is: 7 The recommended level of support for the nondefault bit ordering is: 8 If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering. First of all, a compiler that does not implement the systems programming annex which is optional, is free to reject *any* or *all* representation clauses. Second a compiler that *does* implement the systems programming annex must treat recommended level statements in chapter 13 as requirements. Third, even if a compiler does implement the systems programming annex, it need not recognize any representation clauses other than those that correspond to these statements about recommended level of support. So what does this mean for Bit_Order a) A compiler not implementing the systems programming annex may reject all such clauses. b) A compiler that implements the systems programming annex may reject all such clauses for machines where the word size is not equal to a storage unit = all byte addressed machines = pretty much all machines around these days. So in other words, on a byte addressed machine you cannot expect the non-standard bit order to be implemented at all. Why the apparently surprising restriction? Well let's look at the definition of Bit_Order: 2 A bit ordering is a method of interpreting the meaning of the storage place attributes. High_Order_First (known in the vernacular as ``big endian'') means that the first bit of a storage element (bit 0) is the mostsignificant bit (interpreting the sequence of bits that represent a componentas an unsigned integer value). Low_Order_First (known in the vernacular as``little endian'') means the opposite: the first bit is the least significant. In other words, the attribute affects ONLY the numbering of bits WITHIN a storage unit, it does NOT affect the numbering of storage units. The thinking of the designers was that this is of very limited use on a byte addressed machine, so what's the point of requiring it to be implemented. On a word machine it is more useful. In GNAT, we decided to implement it anyway, even though this is not required, but of course we have to implement it the way the RM specifies, so it only affects the numbering of bits within a storage unit. So for example, if you have: type r is record a,b,c : integer; d : short_Integer; end record; it is meaningless to apply the non-default bit order because bit numbering within storage units is not an issue in this case GNAT will issue a warning in this case that the selection of bit order does nothing. Why a warning? Well it is our experience that lots of people (Marc included I think) expect the specification of bit order to magically fix the difference between big-endian and little-endian representations. In fact not only does it not do this at all, but there is no obvious (or even non-obvious) way to define a facility in Ada that *would* take care of this very difficult data incompatibility in an automatic manner. A few people have suggested ideas, but none of the ideas have held up. So yes, I understand that the implementation in GNAT does not meet Marc's expectations but unfortunately it is the expectations that are fundamentally wrong, the implementation is right, and any other compiler that accepts the same declarations must do the same thing (of course it would not be at all surprising if some other compiler rejected the clause on a byte addressed machine, and any use of the GNAT facility here is likely to be non-portable since it is a non-required, though allowed, extension). Robert Dewar Ada Core Technologies However, the way GNAT (and perhaps other compilers) implement this is > not the way I expected it. I expected on an Intel PC (little endian) when > you say... > for T'Bit_Order use System.High_Order_First; > on a data type that has 'Size=32, that bit zero is the most significant bit > (as it would be on an big endian sgi). That is NOT true. Bit zero is the > MSB of byte zero (the least significant byte) of a four byte value. > > Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit) > are generated after normalizing the values so that 'First_Bit is less than > Storage_Unit. So something like... > for C at 0 range 24..24; > with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0. > This is the most significant bit in a 32 bit value if you applied > High_Order_First to the bit order. > > [sigh] > > It is a pain to define structures that are portable between both big and > little endian machines. Almost as big a pain as the related byte swapping > that is often needed. If someone wants a more detailed explanation of what > we found w/ this, I suggest starting a new thread. > --Mark