knudsen@ihwpt.UUCP (mike knudsen) (11/27/86)
The rationale for Intel and 6502 byte ordering is that it is natural and consistent for *arithmetic* operations, including the adds and subtracts in address calculations. That is, higher addresses have higher-significance bytes. Motorola's ordering makes for slower arithmetic, since you have to go back and fix the carries afterwards. However, it is easier to read values in a Hex dump. More important, tho less generally known, Motorola byte ordering is better for *graphics* bit-blitting, since the bytes have the same left-to-right ordering in the registers as they do in memory. Graphics programs on Intel procs have to swab bytes to undo the automatic swab done by the chip on stores and fetches. Could this be why most graphics-oriented machines use 68K chips?? --mike k -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs (AT&T) (312)-979-4132 (work) You think AT&T cares about CoCos, music, or Star Trek? No? Then, these opinions must be all mine!
srm@iris.berkeley.edu (Richard Mateosian) (11/27/86)
>Motorola byte ordering is better for *graphics* bit-blitting, >since the bytes have the same left-to-right ordering >in the registers as they do in memory. There is nothing to stop you from thinking of the LSB of a register as being on the left and the MSB on the right. A purely little-endian graphics engine (e.g., National's AGCS) is entirely consistent. Some would say it's the only reasonable way to do it. Richard Mateosian ...ucbvax!ucbiris!srm 2919 Forest Avenue 415/540-7745 srm@iris.Berkeley.EDU Berkeley, CA 94705
wen-king@cit-vlsi.UUCP (11/27/86)
In article <1271@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes: >The rationale for Intel and 6502 byte ordering is that it >is natural and consistent for *arithmetic* operations, >including the adds and subtracts in address calculations. >That is, higher addresses have higher-significance bytes. > >Motorola's ordering makes for slower arithmetic, since >you have to go back and fix the carries afterwards. >However, it is easier to read values in a Hex dump. > >More important, tho less generally known, Motorola >byte ordering is better for *graphics* bit-blitting, >since the bytes have the same left-to-right ordering >in the registers as they do in memory. >Graphics programs on Intel procs have to swab bytes >to undo the automatic swab done by the chip >on stores and fetches. As Craig Hansen has said in his previous reply, this debate is pointless. I for one want to see it stopped, and early. Has anyone noticed that the original poster wanted the replies sent via E-mail? I was going to sit tight and shut up myself but I can't stand false information being passed around in this group. Here are the facts: 1) The two orderings are duals. They are symmetrical and self consistent. Anything you can do in one ordering, you can do in the other by taking the dual of all the data, addresses, and operations. 2) It is people - you and me, people who build chips and people who write programs - who are inconsistent and asymetrical. Mirrors does not invert images sideways (as opposed to inverting them upsidedown), its all in our heads. No, Motorola's byte ordering does not make arithmetic operations slower. Bits are stored in the register in the same way as Intel. The only difference is the way addresses are assigned to the individual fields in a register. Nor is there any automatic byte swapping inside Intel's chips. Blitting should not be any more difficult with Intel's byte ordering than Motorola's. The way you pack pixels into words and words into scan lines is what makes all the difference. It is people who are flawed. To date, nobody has come up with a true big-ender machine; not IBM, not Motorola. A true big-ender must have a PC that counts down, and arrays that indexes backward. On the other hand, Intel has adopted a pure little-ender byte ordering in their processors. Now, if only people can learn to write consistent programs on them. I am not flaming the big-enders, just those who mixes them up. The next time you hear somebody claiming one byte ordering is superior than another, you know that he is either confused, misinformed, or he is not talking about byte ordering at all but about one specific software/hardware combination vs. another.
clewis@spectrix.UUCP (Chris Lewis) (11/27/86)
In article <1271@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes: >Motorola's ordering makes for slower arithmetic, since >you have to go back and fix the carries afterwards. Huh? Surely you're not implying that arithmetic in a Motorola CPU (or any other CPU with the same ordering - eg: Pyramids) is done byte at a time upwards in memory? Once a value is in a register, it don't make no never-mind whether the carry wires go "right" or "left". Further, in software extended precision arithmetic (ala pseudo-registers in RAM), you add right-to-left (high to low memory) just as humans do with pencil and paper. No performance differences at all (though, I'll admit the occasional intellectual confusion about where the durn pointers are supposed to start from, as opposed to where they end!). The only reason why I dislike Intel ordering is that it's hard to read hex dumps. And split octal. The one I really loved-to-hate is: byte2:byte3:byte0:byte1 (longs on UNIX PDP11's - the "NUXI Problem" - we all have our quirks) -- Chris Lewis Spectrix Microsystems Inc, UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis ARPA: mnetor!spectrix!clewis@seismo.css.gov Phone: (416)-474-1955
berger@clio.Uiuc.ARPA (12/02/86)
That's just not true. There IS some advantage to the Intel scheme when you're talking about chips with an 8 bit bus doing 16 bit address calculations. The low order byte is needed first, and is fetched from memory first - then the address counter is incremented. This is surely faster than incrementing the address counter, fetching, decrementing, fetching, and incrementing twice. This advantage is eliminated with a 16 bit bus.
jkg@gitpyr.gatech.EDU (Jim Greenlee) (12/03/86)
In article <16900001@clio> berger@clio.Uiuc.ARPA writes: >This is surely faster than incrementing the address counter, fetching, >decrementing, fetching, and incrementing twice. I'd be surprised if any of the "big-endian" (did I get that right? :-) microprocessors go to all that trouble. I think it's more likely that they read the data from memory in the order that it appears, and then do a byte swap within the CPU (or maybe it's the "little-endians" who do all the swapping :-). I honestly don't see what difference it makes - I mean, after all, both schemes work, don't they? Jim Greenlee -- The Shadow...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jkg Jryy, abj lbh'ir tbar naq qbar vg! Whfg unq gb xrrc svqqyvat jvgu vg hagvy lbh oebxr vg, qvqa'g lbh?!
dennisg@fritz.UUCP (12/10/86)
In article <2758@gitpyr.gatech.EDU> jkg@gitpyr.UUCP (Jim Greenlee) writes: >do all the swapping :-). I honestly don't see what difference it makes - >I mean, after all, both schemes work, don't they? Both schemes do work, in isolation. The problem is when a network has both types of machines on it. Somebody is going to have to incur the penalty for swapping. Do you want it to be your machine? Of course the cost could be time, by doing the swap in software. Or you can do it in silicon and copper... and the box is more expensive. And if you aren't talking on a network, you still have the problem of integrating a spiffy big-endian peripheral chip with that little-endian CPU you have.