| |||||||||||||
How Open Formats Encouraged Open Source (O'ReillyNet)How Open Formats Encouraged Open Source (O'ReillyNet)Posted Feb 23, 2007 21:52 UTC (Fri) by accensi (guest, #11754)Parent article: How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet)
The author make a mess of different concepts. If I remember well, memory storage in IBM 3x0 and PDP/Vax for strings were done in the same order, from left to right. Binary data was different. the famous and old distinction between "little endian" and "big endian" way of ordering the bytes from left or right when storing a word in memory, from a register. See http://en.wikipedia.org/wiki/Endian
Other important differences were the basic unit of I/O in records, of fixed size in IBM (normally of multiple of 80 bytes, the size of an IBM/Hollerith punched card), and variable size in DEC world, perhaps from its use of paper tape.
(Log in to post comments)
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Feb 26, 2007 18:52 UTC (Mon) by MBR (guest, #43632) [Link] I'm afraid you're misremembering how strings were stored. When I was in DEC's Small Systems Group, I wrote large parts of RT-11 MU-BASIC for the PDP-11, and before that in college, I'd spent years writing assembly code for the IBM 360. So I was pretty sure I was remembering correctly when I wrote the article. But just to be sure, I dug out my old PDP 11/45 Processor Handbook and my old BAL-360 manual and double-checked before I submitted the article.
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Feb 26, 2007 23:24 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] BTW, someone had commented on the article that big vs. little endian only makes a difference when the machine's word-size is larger than a byte. That's hardly true. If you try to manipulate any quantities larger than a byte, you need to have a well known way of breaking it down. The 6502 and 6800 were little endian as I recall, because 16-bit addresses were stored little-end first. Little endian has the additional advantage that numbers are stored in the order in which you operate on them. (Think about it... addition, at least as it was taught to you in grade school, is little endian.)
Now, didn't the later PDP / VAX machines do something funky with how 32-bit values got broken down into 8-bits? I seem to recall a "middle endian" with a 2,3,0,1 (or 1,0,3,2 depending on how you look at it) byte order because it was big endian between 16-bit halves of the 32-bit word and little-endian among the bytes in each half-word, or vice versa. That'd be where NUXI vs XINU comes in...
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Feb 28, 2007 19:27 UTC (Wed) by MBR (guest, #43632) [Link] See my comment below in response to "PDP-endian" byte order. The PDP-11 addressing for multi-word data really confused the issue. Note that the VAX was its own series and was not part of the PDP series. I think DEC may have fixed the PDP-11's weird low-endian byte order but big-endian word order when they designed the VAX architecture, but I'm not sure because by the time the VAX came along I was doing more coding in high level languages and not so much in assembly language.
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Mar 1, 2007 9:03 UTC (Thu) by charris (subscriber, #13263) [Link] I do recall that weird byte order for floating point numbers, but I don't remember it for integers.
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Mar 1, 2007 16:47 UTC (Thu) by brouhaha (guest, #1698) [Link] The 6800, 6809, and other 8-bit Motorola microprocessors were big-endian. As you say, the 6502 is little-endian.
The 68000 was interesting in that it was mostly big-endian, but the bit ordering used by the bit instructions was little-endian. When they added bitfield instructions to the 68020, with bitfields that could span words, they had to adopt big-endian bit numbering for those instructions to make it work well.
IBM, on the other hand, uses consistenly big-endian numbering for both bits and bytes. I've always thought it aggravating to deal with bytes and words that have bit zero as the most significant bit, but at least it is consistent.
How an Accident of Hardware Design Encouraged Open Source (O'ReillyNet) Posted Mar 1, 2007 17:26 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Ok, I misremembered then. I didn't have much opportunity to program the 6800 series back in the day--just a few brushes with a 6875 and a 68HC11.
Big endian bit numbering is supremely annoying to me. The TI Home Computer numbered its busses in big-endian. A0 was the MSB of the address bus. Depending on whether you were looking at the 16-bit or 8-bit portion of the bus, the LSB was A14 or A15. (Yes, I did program 9900 assembly. It was my first assembly language.)
It works, but it only works well if you left-justify addresses as opposed to right-justifying them. And that only works if you know what your longest address is. What happens if the machine goes to 32 bits? :-)
(I'll stop now. I had written more, but thought better of it.)
Endian consistency Posted Mar 3, 2007 5:41 UTC (Sat) by ldo (subscriber, #40946) [Link] IBM, on the other hand, uses consisten[t]ly big-endian numbering for both bits and bytes. Actually, there is no completely consistent big-endian system. There are three different decisions to be made as far as endianness goes:
The IBM convention gets consistency among the first two, but not the third. The only way to get consistency among all three is to go little-endian. Another point is that, even on big-endian architectures, registers tend to effectively be treated as little-endian--when you load/store quantities less than the full register size, you get the least-significant end of the register, not the most-significant end. Again, the only way to be completely consistent is to go little-endian.
|
|||||||||||||