🚀 go-pugleaf

In article <willmore.726511292@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) writes:
>The other way fixes the load problem.  Say you want to read an 8
>bit value starting at address 0.  The first byte read goes in the
>low order part of the register, the rest is cleared.  To load a
>16 bit value, address 0 is placed in the low byte of the register
>and the next byte at address 1 is placed in the next higher byte
>of the register.  That way, a 32 bit or more number can be at a
>fixed location and you can optionally load 8 bits, 16 bits, or the
>full 32 bits without having to adjust your address register.

Actually, I think that it's not the 'load' problem so much as it is
the 'add' problem. When you are going to do an add on a machine with
1 byte adder, you want the low order bytes of both operands first,
and the high order bytes last, because that is the direction in
which the carry propagates.

Noting that a great many of the operands to the adder are literals
in the the instruction stream (i.e., both literal constants and
memory address offsets), on a machine with a narrow data path,
one would like to arrange things such that, at least for constants
in instructions, normal instruction prefetching encounters
low order bytes first. Once you chose that format in the I-stream,
doing it for other data follows for all kinds of reasons.

Given that Intel x86 started as narrow data flow stuff, it's
not surprising that it ended up with low-byte-first.

For architectures which weren't so biased by a narrow data flow in
their earlier years, high byte first makes more sense, if only to
allow arithmetic values in dumps to be read more easily. (This
indeed, may vary according to the native language in use, but the only
languages which enter into the question are the native languages
of the early developers who first established the conventions, and
I think these were primarily of European/USA origin.)

Wally Bass