Query on portable bit extraction

[Mark Johnson <Mark_H_Johnson@Raytheon.com>]

We have code that we want to run on both a big (sgi) and little (pc)
endian machine. As an example, the layout of the data in memory is...
[big_endian bit order]
Byte  0 1 2 3 4 5 6 7
21 -  X X X Y Y Y Y Y
22 -  Y Y Z Z Z Z Z Z
where we need to extract XXX as the "wait code", YYYYYYY as the "value",
and ZZZZZZ is a pad area (don't care).

On the big endian machine it was coded like this...
 Wait := (byte 21) / 2**5;
 T1 := (move bytes from bytes 21 & 22)
 T2 := T1 / 2**6;
 T1 := T2 / 2**7;
 T1 := T1 * 2**7;
 Value := T2-T1;
which won't work on the PC unless we swap the bytes in the first
assignment to T1 and looks ugly as all get out.

Thinking of records & representation specifications, I'd like to be able
to do something like this...
  subtype Wv is Natural range 0..7;
  subtype Vv is Natural range 0..127;
  subtype Pv is Natural range 0..63;
  type Wait_Value is
    record
      Wait : Wv;
      Value : Vv;
      Pad : Pv;
    end record;
  for Wait_Value use
    record
      Wait at 0 range 0..2;
      Value at 0 range 3..9;
      Pad at 1 range 2..7;
    end record;
  for Wait_Value'Bit_Order use System.High_Order_First;
which looks pretty reasonable until I get the following GNAT error
messages on the PC...
 error: attempt to specify non-contiguous field not permitted
 error: (caused by non-standard Bit_Order specified)
Hmm. After drawing it out on the white board - sure enough, the bits are
not contiguous, a byte swap is needed. Assuming I do a byte swap
somewhere, I recode the representation specification to be...
  for Wait_Value use
    record
      Wait at 1 range 5..7;
      Value at 0 range 6..12;
      Pad at 0 range 0..5;
    end record;
(assuming System.Low_Order_First bit order) which works as expected.

So - I can probably code up a portable version based on...
 - byte swap or not based on System.Default_Bit_Order
 - representation specification also based on System.Default_Bit_Order
but is this the best way to do it or should I stick w/ the original
code?

Thanks.
  --Mark Johnson
  <mailto:Mark_H_Johnson@Raytheon.com>