🚀 go-pugleaf

In article <1hquujINNmov@fido.asd.sgi.com>, pj@sam.wpd.sgi.com (Paul Jackson) writes:
> In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
> |> 01101001 may mean `105' (big-endian) or `150' (little-endian)
> 
> Big and little endian refer to the order of bytes within words,
> not to the order of bits within bytes.

That is a convention in *your* head. There is no reason why big endian can't
be made to mean to apply to bits if you want. For the purposes of his example, 
he is correct. For human interpretation of binary (at least how I was taught
at school :-) ), you are correct. For various computer architectures, who
knows? I've seen some odd boxes in my time; I'm not even sure it makes sense
at this level anyway, since the circuit designers will ensure the correct
bits get where they're going.

If you remember my post to do with date format a while back I referred to
big-endian and little-endian dates (hmmm, maybe in private email I did, maybe
not on the net). Big and little endian is just a concept.

I do think, in practice, it may be confusing to deal with different ordering
of bits in bytes, but then again in X, the XImage format can have data in
8, 16, 32 bit formats, with MSB or LSB ordering of bytes, and with LSB and MSB
ordering of bits too! Total: 3 * 2 * 2 formats = 12 possible formats for
XImage data. This is an exmaple of big and little endian byte and bit ordering.
This was provided to ensure that most (if not all) systems could represent
XImages efficiently for the particular processor used.
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.