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 15:15:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!cyclone.swbell.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3CD1B5D0.9C81D65C@raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is this a GNAT bug??? 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> <3cd18c55.86305947@news.blueyonder.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 02 May 2002 16:55:28 -0500 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1020376621 192.27.48.39 (Thu, 02 May 2002 16:57:01 CDT) NNTP-Posting-Date: Thu, 02 May 2002 16:57:01 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:23458 Date: 2002-05-02T16:55:28-05:00 List-Id: Nick Roberts wrote: > > 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). > I guess I look at the problem differently - I either... - care what order the bits and bytes are in memory OR - care what order the bits and bytes are in a register I generally don't care what the register values look like in memory - after all, I only manipulate them using registers. If I do a byte swap at the interface to convert a 16 or 32 bit value from big to little endian format, I get the appropriate value when loaded into a register. I almost always care what format data is in memory when dealing with an external interface - hence the emphasis on getting representation clauses with bits and bytes correct in those cases. When the compiler manipulates that data in registers, it hides the details from me. > [snip] > 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). > Not quite true. The PDP-10 was a big endian 36 bit machine (page 2-15, PDP-10 System Reference Manual). The byte manipulation functions on that system used bit zero as the most significant bit and allowed you to extract "S" bits at an offset of "P" (actually 36-P). There were load and deposit byte instructions w/ and w/o increment of the byte pointer. You could easily manipulate a stream of 8 bit bytes (e.g., from mag tape) but text was more often stored as five 7 bit bytes (one bit pad) in each word. I am not sure for other 36 bit machines what they used - I think Multics (Honeywell DPS8/M) was also a big endian machine, but I couldn't find a good reference at http://www.multicians.org/ to confirm that. Multics stored text by the way as 9 bit bytes. > [snip] > 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. Sorry, the same example - the PDP-10 System Reference numbers bits in a word from zero through 35. Actually, I think it depends more on the original developer - were they a "C" or "Pascal" type of person :-). --Mark