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,13f10cac2d21b84f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-02 13:20:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!cox.net!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news-binary.blueyonder.co.uk.POSTED!53ab2750!not-for-mail From: nickroberts@blueyonder.co.uk (Nick Roberts) Newsgroups: comp.lang.ada Subject: Re: Is this a GNAT bug??? Message-ID: <3cd18c55.86305947@news.blueyonder.co.uk> References: <3CC992D6.A87A3443@raytheon.com> <5ee5b646.0204291844.21d7f5f0@posting.google.com> <3CCF12E9.6CA14A29@raytheon.com> <3cd06b13.12244473@news.blueyonder.co.uk> <3CD145A5.214C67E8@raytheon.com> X-Newsreader: Forte Free Agent 1.21/32.243 Date: Thu, 02 May 2002 20:19:59 GMT NNTP-Posting-Host: 62.30.113.100 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-binary.blueyonder.co.uk 1020370798 62.30.113.100 (Thu, 02 May 2002 21:19:58 BST) NNTP-Posting-Date: Thu, 02 May 2002 21:19:58 BST Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.ada:23451 Date: 2002-05-02T20:19:59+00:00 List-Id: On Thu, 02 May 2002 08:56:53 -0500, Mark Johnson wrote: >> Am I actually correct? > >I believe so, but I am not sure what you are trying to show with your >examples - the values as loaded into a register? I was showing the in >memory representation of the data for the two byte orders. Note that it >takes different code to solve the "equivalence problem" for in memory >and in register representations. I wasn't trying to show values as loaded into registers, Mark. I was trying to show the difference in the ways in which big-endian and little-endian machines store their integers in memory. The Bit?H/L rows were intended to show the bit numberings of the data as it would be numbered if loaded from memory into a register (8, 16, or 32-bit). As you infer, big and little-endianness is about both bit numbering and byte ordering; I was trying to demonstrate the difference in byte ordering as well as the difference in bit numbering. The reason why I wanted to show the in-memory representation of 16 and 32-bit integers, as well as 8-bit ones (bytes), is because for some machines (or Ada implementations) Streams.Stream_Element'Size could be 16 or 32 bits (rather than 8). Since the issue of endianness is most likely to affect those doing stream-oriented I/O of a record type, the way a 16 or 32-bit stream element is stored in memory is likely to be of significance. For those who may be wondering, Streams.Stream_Element'Size could of course be something other than 8, 16, or 32. But then on such a machine the issue of being big-endian or little-endian is irrelevant (as the machine will be neither). Note that the diagrams of both Mark and myself assume a storage element size of 8 bits. If this is 16 or 32 bits, different diagrams would be more appropriate. Big endian (System.Storage_Size=16, Bit_Order=High_Order_First) SE 0000000000000000 1111111111111111 ... Bit16VH 1111110000000000 1111110000000000 ... Bit16VL 5432109876543210 5432109876543210 ... Bit16H 0000000001111111 0000000001111111 ... Bit16L 1234567890123456 1234567890123456 ... Bit32H 0000000001111111 1112222222222233 ... Bit32L 1234567890123456 7890123456789012 ... Ind 0000000000111111 1111222222222233 ... -ex 0123456789012345 6789012345678901 ... Little endian (System.Storage_Size=16, Bit_Order=Low_Order_First) SE 0000000000000000 1111111111111111 ... Bit16VH 1111110000000000 1111110000000000 ... Bit16VL 5432109876543210 5432109876543210 ... Bit16H 1111110000000000 1111110000000000 ... Bit16L 5432109876543210 5432109876543210 ... Bit32H 1111110000000000 3322222222221111 ... Bit32L 5432109876543210 1098765432109876 ... Ind 1111110000000000 3322222222221111 ... -ex 5432109876543210 1098765432109876 ... Big endian (System.Storage_Size=32, Bit_Order=High_Order_First) Bit32VH 33222222222211111111110000000000 ... Bit32VL 10987654321098765432109876543210 ... Bit32H 00000000011111111112222222222233 ... Bit32L 12345678901234567890123456789012 ... Ind 00000000001111111111222222222233 ... -ex 01234567890123456789012345678901 ... Little endian (System.Storage_Size=32, Bit_Order=Low_Order_First) Bit32VH 33222222222211111111110000000000 ... Bit32VL 10987654321098765432109876543210 ... Bit32H 33222222222211111111110000000000 ... Bit32L 10987654321098765432109876543210 ... Ind 33222222222211111111110000000000 ... -ex 10987654321098765432109876543210 ... Finally, I believe big-endian bit numbering conventionally starts from 1 (rather than 0), and I wanted to show this. (Of course, this is only a convention. I think it is widespread, but certainly not universal. The PowerPC is normally big-endian as regards byte ordering, but the IBM documentation numbers the bits from 0 for the LSB to 31/63 for the MSB; the situation is further confused by some PowerPCs being able to operate in little-endian mode!) But this can be a confusing subject, and (as I've proved several times on comp.lang.ada) I'm not exactly immune to error. I hope the above makes sense, but please say if it doesn't!