🚀 go-pugleaf

The argument for little endian is: term n of the polynomial representing
a number is at offset n. That should save some effort now and then and
makes more conceptual sense to those of us who think in these terms
(rather than paper notations which, as discussion here shows, are
totally arbitrary).

The argument for big endian is: sort orders work out to be the same for
integers and strings. (This is the place where the "order of writing"
really matters - though it's really pure coincidence that they coincide).

IMO, the sort order argument is weaker than it looks, because the
topology of strings is rational and not integral - so it's sort of
natural that they should be different.

That last observation prompts me to suggest that bytesex inconsistency
should be handled *not* by having byteswap operations, but rather by
laying out structures and arrays (including strings) in a
**negativegoing** direction on whatever you deem to be the "hostile"
architecture (as you might guess from the above, I vote for bigend as
"hostile"). Except in the case of machines that use inconsistent bit-
and byte-sex (68000 case in point) this lets you use the *same* layout
logic for *both* genders.

You can even share structures between the two architectures if one of
the sharers negates its addresses (whether in software or in hardware).
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------