wen-king@cit-vax.Caltech.Edu (King Su) (01/05/89)
In article <4008@hubcap.UUCP> hutch@delft writes: >Actually, where most little-endian machines screw up is storing the <bits in the byte in the wrong order. It is good to hear that somebody got it >right and stored a one as 100000...0000 rather than 00000001000...000. No No No. Little-endian machines do store one as 100000...0000 where the left most digit (the 1) is the LSBit. This is consistent with the fact that in little-endian machines the left most byte of any sequence of bytes is also the LSByte. It is you (and me, and almost everybody else for that matter), that insisted on writing bit sequences in a big-endian order - MSBit first. It is us that writes one as 00000001000...000; any screw-ups happen only in our heads. In general, in little-endian machines, the left most storage unit of any sequence of storage units is also the least significant storage unit of the sequence. However, we have the habit of writing the sub-fields of a storage unit in the big-endian order. We also have the habit of storing strings in the big-endian order - the most significant character goes to the left most storage cell. Both of these give a little advantage to big-endian machines. However, if by our minds happen to work the other way: if we were used to write sub-fields of a storage unit so that the left most field is the LSField, and if we were to store the first character of a string in the right most storage cell, then the relationship between the two conventions would be reversed. It is all in our heads. As for the advantage that is traditionally claimed by the small-endian machines (that it simplifies many extended precison arithmatic operations, including BCD string operations and double word operations) we really have to look a little closer to see whether it is caused by the difference in the byte-ordering convention. Take the double word operation for example, "add-immediate double-word value to register" instruction may look like this in a little-endian machine: <op-code> <LSWord> <MSWord> big-endian machine : <op-code> <MSWord> <LSWord> This little endian machine has a slight edge because half of the addition operation can take place while MSWord is being fetched. (I am not saying that any such disadvantages cannot be compensated in a real big-endian machine.) However, if we look carefully, we see that in the case of the above little-endian machine, the PC moves from low address to high address which is the direction of increasing word-significance; yet, the big-endian example has PC move in the direction of decreasing word-significance. Suppose we have a big-endian machine in which instruction number 0 is stored in the least significant program word (high address, or right most) and the PC moves from high address to low address, we will have: big-endian machine : <MSWord> <LSWord> <op-code> This big-endian machine will be exactly as good as previous little-endian machine in handling double word operations. Similarly for character string comparisons, a little-endian machines will be exactly as good as a big-endian machines if we store the strings backward from the way we store them now (which means we change the way we index the bytes, s[3] = address of s - 3). There is nothing wrong with either the big-endian or the little-endian byte-ordering conventions; any difficulties that we encounter are in our heads; any perceived differences between machines of the two conventions are really artifacts of how each machine move their PC and how it index arrays, and has nothing to do with byte ordering. In fact, given any processor, one can construct another processor that is exactly as good as the first one, but having the opposite convention. Assuming of course that we don't read the hex-dumps. The things that can be argued about are things like the direction of PC movements and array indexing conventions. Byte ordreing by themselves do not make any real difference. -- /*------------------------------------------------------------------------*\ | Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers | \*------------------------------------------------------------------------*/