Now I finally understand and, consequently revoke my warning words against using 'endianess' in a manual. :D
What? I understand it, why shouldn't everyone else? :-/ B??var -- Enlightened on a Friday 2009/5/22 Jeremy H. Griffith <jeremy at omsys.com>: > On Fri, 22 May 2009 13:36:11 +0000, Bodvar Bjorgvinsson > <bodvar at gmail.com> wrote: > >>Regarding the "endianess", I had a problem some 13 years ago with some >>UNIX software that was supposed to work on Linux. It did not. I sent a >>query to an Icelandic guy on the "Basic Linux Training" list I >>subscribed to and he came up with a solution. Then he expained to me >>that there was a difference between Linux an UNIX that one used big >>endian and the other little endian in the same code of software. > > In current computer systems, there are two kinds of > "endianess", called "LSB (Least Significant Byte) > first" and "MSB (Most Significant Byte) first". > For any given system, what determines this is not > the operating system (Linux, Windows, etc.), it's > the processor (CPU). ?All Intel CPUs are LSB first; > others, like Sun SPARC and Motorola 68K, are MSB > first. ?So Linux on a Sun SPARC would be MSB first, > but on an Intel box it would be LSB first. > > Technically, the difference is indeed *byte* order, > not *bit* order (which is constant). ?Suppose you > have a hex number 0xABCD. ?The most significant > byte is 0xAB; the least significant byte is 0xCD. > Now imagine that you store this number in memory > at address 0. ?;-) ?You will get: > > Location ?SPARC ?Intel > 00000000 ?0xAB ? 0xCD > 00000001 ?0xCD ? 0xAB > > Well-designed programs where portability matters > will work with *either* CPU. ?They do this by not > caring what the storage order in memory is, and > always accessing multibyte numbers through a set > of functions that work regardless of byte order. > For example, Mif2Go was originally developed on > a Sun SPARC system, then ported to Windows very > easily because it followed those design rules. > > There's actually a third flavor, but it was used > only on the DEC PDP-11. ?Since the last of those > is probably in the Smithsonian, you won't see it > in current software. ?It is the same as Intel > for two-byte numbers (shorts) but switches the > byte pairs for 4-byte numbers (longs). ?So the > number 0x12345678 is 0x34, 0x12, 0x78, 0x56. > > Endianness also affects Unicode, in the UTF-16 > and UTF-32 encodings of it, but *not* in UTF-8. > It is the reason for the UTF-16 BOM (Byte Order > Mark), U+FEFF, ?In UTF-16 Big-endian (MSB first), > the bytes are 0xFE 0xFF. ?In UTF-16 Little-endian > (LSB first), they are 0xFF 0xFE. ?UTF-32 adds two > zero bytes, before it for Big and after for Little. > > The Unicode BOM may also be used as an encoding > signature, but I digress... ? ;-) ?Good thing > it's Friday, eh? > > HTH! > > -- Jeremy H. Griffith, at Omni Systems Inc. > ?<jeremy at omsys.com> ?http://www.omsys.com/ > _______________________________________________ > > > You are currently subscribed to Framers as bodvar at gmail.com. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/bodvar%40gmail.com > > Send administrative questions to listadmin at frameusers.com. Visit > http://www.frameusers.com/ for more resources and info. > -- "Life is not only a game--it is also a dance on roses." --Fleksnes (Rolv Wesenlund)
