The 8086 only had 20 address lines, and Intel didn’t foresee it as becoming the successful line of processors that it evolved into. Instead, Intel thought that the 8086 would have a relatively short life, which isn’t an unreasonable assumption if you look at the previous generation of 8 bit computers.
I have to admit though that I thought it was a bit short sighted when I first saw it too.
Intel thought that the future was with the iAPX432 architecture. Instead, what happened was that the IBM AT used the 80286, due to backwards compatibility, cost, and performance. The iAPX432 series ended up having fairly poor performance, and basically flopped. It had a lot of neat ideas in it, but it was a complicated and clunky architecture (IMHO) and I’m not surprised that no one managed to come out with a computer using it that could compete with the IBM AT.
The 286 era ushered in the IBM clones, and the PC architecture really took off. That pretty much cemented the x86 architecture’s dominance and turned the iAPX432 into something that most folks haven’t even heard of today.
The iAPX432’s initial implementation was a 16 MB address space. It used the same basic idea of memory descriptors as the 286 (though a different implementation) so its architecture was not limited to 16 MB.
I knew there were a lot of computing people here, but jeez! Who knew there were so many that had to get into this level of crap?
I always knew that I was getting into the Real Stuff when I started having to read the bits. Endian issues was only one of many causes for having to dig that deep.
I was recently writing code to send requests over the internet to services provided by another company. The requests themselves are in JSON, so that’s all text, no endianness issues. However, one of the header fields is a cryptographic hash, using a private key, so ensure that we are who we say we are. And the thing that is hashed is a binary blob, and one part of the binary blob is a 32-bit integer representing the current time. And that integer has to be in the proper endianness.
Note, however, that once I wrote this code to send the messages around, many other programmers will be able to call my code and send messages without ever having to worry about the endianness at all. So it still matters, but 99.9% of the time if you’re doing it right, no one has to think about it.
I follow stuff on a board that has a sub-forum devoted to modding TiVo DVRs. In particular, replacing and expanding the HD for more recording time. (I’ve done this on 2 TiVos and another DVR myself.)
Apparently, TiVo used on byte order on the HD in the first series, swapped the byte order for series 2, 3, and 4 and now have gone back to the original order for series 5 (Roamios). 'Cause of the processor used by the DVR, you know. Utilities to do the copying and expanding have to be adapted to deal with all this. Note that these utilities are run on separate machines, so you just can’t rely on the processor’s default to just “handle it”.
While TiVo is fine with this level of modding (one employee has been assigned to respond to issues found with the OS), they don’t make any info publicly available so it’s all figured out by staring at the bytes.
Yes! I just ran into this a couple of months ago with an Oracle database conversion. Oracle has what is called ‘transportable tablespaces’. It means that you can easily convert an Oracle database from something like Unix to AIX.
We wanted to test a database hosted on Sun Unix migrated to Linux Redhat. I assumed that as Unix and Linux are similar, it should be easy. Silly me! The Sun Platform is big endian and Linux is little endian. I had to jump through a few major hoops to get transportable tablespaces to work.
The most common need to address endianness, as others point out, is when formatting messages for an external standard. But there is another case where endianness matters: when a field needs to be addressed with different sizes. This will usually arise only when trying to squeeze out maximum performance. For example, in a bit field where most accesses use a natural long size for performance, you may want to access a single byte.
Here’s a more exotic example:
union {
short sh[2];
long lo;
} A, C;
...
C.lo += A.lo; // C.sh[0] += A.sh[0], C.sh[1] += A.sh[1];
Replacing two 16-bit adds with one 32-bit add will save time, but when you dig into details you’ll find that maximum precision requires different methods of packing negative numbers into sh[HI] and sh[LOW].