🚀 go-pugleaf

>  >One last point:  As a systems programmer, I think it would be nice
>  >if data formats, addressing, instruction formats, and notation were
>  >all consistently big-endian or little-endian.
> 
> That's one of the things I don't like about the 680?0 series, I would
> expect an integer with a value of 0x12345678 to be in memory as either
> 12345678, or 87654321, or 78563412 even, but not 34127856. I consider
> that "middle-endian".

Could you please explain how you got "34127856" out of this?  If you read
the nibbles in a byte left-to-right, and sequence through the value
0x12345678 from byte 0 to byte 3 (which is the same as reading the bytes in
a word left-to-right), you get "12345678".

The only way *I* can see getting "34127856" is if you read the first 16-bit
word of 0x12345678 first (i.e., the 16-bit word whose 0th byte has the
lowest address) followed by the second 16-bit word; read the low-order byte
of the word first (i.e., the one in the least-significant bits, i.e.  the
one with the *highest* address), and read the two nibbles of each byte from
left to right (i.e., the nibble in the most-significant bits first).  If you
read the bits from the most-significant bit to the least-significant bit,
you are also reading the (bytes, words) from the lowest address to the
highest, and you get "12345678".

The 680x0 is perfectly consistently big-endian here; it's your way of
reading it that's "middle-endian" and inconsistent.

>  >All the mainframes that I know of have big-endian data formats; so does
>  >the (by far) most popular microprocessor for engineering and scientific
>  >use (MC68020).
> 
> Does that mean that if it uses a National or Intel chip it isn't a
> workstation?

Of course not; no reasonable reading of his statement could possibly lead to
that conclusion.  1) It didn't say "workstation" anywhere.  2) It didn't say
that only Motorola chips were used in engineering and scientific machines,
just that they were the most popular chip for those sorts of machines.

A couple of points:

	1) The aesthetics of an architecture is rather subjective.  Person
	   A may think that a machine that has a nice cute one-to-one
	   mapping between constructs in some high-level language and
	   machine primitives is Beautiful and therefore Good; person B
	   may think that a machine that has primitives that can be
	   used as simple building blocks to express the operations actually
	   performed by programs is Beautiful and therefore Good.  As such,
	   the aesthetics of little-endian, big-endian, middle-endian, or
	   whatever machines is really rather irrelevant to their merits as
	   designs.

	2) The chances that any given vendor will change their byte order
	   because 1) people say the current one is ugly or 2) some
	   committee decides that the other byte order is the One True
	   Way are somewhere between zip and nil.  You're just going to
	   have to live with different byte orders, and use data
	   representation conventions when exchanging data between machines.