Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!decwrl!labrea!lindy!news From: GQ.RLG@forsythe.stanford.edu (Dick Guertin) Newsgroups: comp.arch Subject: Re: 'big endian' and 'little endian' - first usage for computer Message-ID: <1840@lindy.Stanford.EDU> Date: 29 Jan 89 00:42:22 GMT Sender: news@lindy.Stanford.EDU Lines: 37 I'm surprised that the portability issue of code (in C or any other language) for things like Data Base Management Systems has not been raised. This is where I'm finding a BIG headache when it comes to the big-endian or little-endian approach to data storage. Both of these systems lay out "strings" the same way, from lowest address to highest address for the English (left-to-right) order of reading. This makes comparisons of "strings" the same on all machines. When such "strings" are written into a Data Base, they are transportable. But that is not true of multi-byte values. When written by a big-endian machine, the result is not readable by little-endian machines...and vice-versa. Another important consideration is the collating sequence of positive values written as the keys of records that also can receive "string" values as keys. Unless the TYPE of the data is included in the data, the key search algorithm hasn't got a clue when values are intermixed with "strings" on little-endian systems. In the big-endian systems, the sign-bit of values can be flipped and sent to the file using "string" match operations to place the key into proper collating sequence. This is NOT TRUE for little-endian systems. Therefore, I believe big-endian storage of data is superior since retrieval algorithms can be blind to data type. All data, be it "string" or , sorts properly on big-endian systems when the sign-bit is flipped for values. That's something that can easily be done when building record keys, and then the TYPE of the key doesn't have to be considered any longer. On a little-endian system, not only does the sign-bit need to be flipped, but the data bytes need to be reversed in the stored record so "typeless" searches can be performed by the Data Base Record Manager. A Data Management System needs to be sensitive to big/little endian machines, and that makes transportability of such systems a matter of concern to the developers. Just another headache!