Bit_Order useful [was Query on portable bit extraction]

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

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" <jrcarter@acm.org> 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.