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,91e38895ea853f4b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-28 11:16:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!ppp-2-45.cvx4.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Bit_Order useful [was Query on portable bit extraction] Date: Sun, 28 Oct 2001 19:07:32 -0000 Message-ID: <9rhlhr$u11j3$1@ID-25716.news.dfncis.de> References: <9req9o$tlsg8$1@ID-25716.news.dfncis.de> <3BDB5FB6.94899C3C@acm.org> NNTP-Posting-Host: ppp-2-45.cvx4.telinco.net (212.1.149.45) X-Trace: fu-berlin.de 1004296572 31491683 212.1.149.45 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:15315 Date: 2001-10-28T19:07:32+00:00 List-Id: I know there are some big-endian machines (the more recent ones, perhaps) whose manufacturers' documentation number the LSB as 0 and the MSB as 31 or 63. Maybe some of the older ones are as Jeff suggests, although this scheme strikes me as weird mathematically: doesn't it make sense to have a bit numbering where the value of bit n (that it contributes, when it is 1, to the value of the integer it is part of) is 2^n? In fact, having said that, I think I've managed to convince myself that Bit_Order is useful anyway. In the RFCs, the sformat of the IP, TCP, UDP etc headers are (mostly?) defined in terms of 32-bit words, and the bit numbers in the diagrams have bit 0 as the MSB and 31 as the LSB. I guess the RFCs can't be considered too esoteric, and in this case Bit_Order helps one to make the definition of a record representation clause, e.g.: type IP_Header is record Version: ... IHL: ... ToS: ... Length: ... Ident: ... Flags: ... Offset: ... TTL: ... Protocol: ... Checksum: ... Source: Internet_Address; Destination: Internet_Address; end record; for IP_Header'Bit_Order use High_Order_First; W32: constant := 32 / System.Storage_Unit; pragma Assert(System.Storage_Unit mod 8 = 0); for IP_Header use record Version at W32*0 range 0..3; IHL at W32*0 range 4..7; ToS at W32*0 range 8..15; Length at W32*0 range 16..31; Ident at W32*1 range 0..15; Flags at W32*1 range 16..18; Offset at W32*1 range 19..31; TTL at W32*2 range 0..7; ... end record; And I think this clause will work on any implementation regardless of its default bit order, and provided its storage unit is a multiple of 8. Useful enough for me. Again, someone please say if I'm wrong about this, having just proved once again that I (often :-) make mistakes. Otherwise, my apologies. May I please emphasise that my criticism was not malicious (and never is). Finally, there's still a need (in terms of significant convenience) for something like my proposed Octet_Order isn't there? PS: Bit_Order doesn't solve the problem of a 1-based bit numbering scheme. Do we need a Bit_Numbering_Base? -- Nick Roberts "Jeffrey Carter" wrote in message news:3BDB5FB6.94899C3C@acm.org... > Nick Roberts wrote: > > > > AI95-133 confirm's this thread's view that the Bit_Order attribute is purely > > about how to interpret bit numbers in a record representation clause. As > > such, I'm afraid I think it was misconceived. There's no need for it on any > > machine, and it doesn't solve the problem that needs solving (that of big > > and little endianness). Does anyone have an example where Bit_Order was > > actually useful (or vital)? > > I think you're mistaken. I recall (a) processor(s?) on which bit 1 was > the MSB and bit 8 the LSB of a byte. Many big-endian machines use lowest > bit # = MSB.