The Missing Angle
It feels a bit like the question misses the most important point about the whole 8086 project over discussing implementation details:
8080/85 compatibility
The 8086 was intended as a stop-gap measure for CPU sales until the all-solving i432 family was done(*1). One should not forget that Intel's (*2) main customer base was what now is called embedded systems (*3). Back then like today, systems grew faster than resources and 8080/85 family users were asking for a follow-up satisfying that need without rewriting all code.
The 8086's main selling points were
- More memory than the 8080/85
- Close compatibility to the 8080/85
That close compatibility is not only visible in the 8086 register set but also in the instruction formats - no other 16-bit CPU 'wasted' so much code space for single-byte opcodes. With few exceptions all 8080 instructions had 1:1 8086 counterparts, enabling static and mostly automatic translation.
For code, address alignment isn't a big deal (*4), but it is for data. Data addresses and their relation are deeply engraved in code - with assembly (maybe) even more. And that is where a requirement for word alignment would hit hard: The 8080/85 does not know such thing as word alignment and no programmer would have cared until that point.
Anyone who ever had to change structures that are tightly fit (*5) to memory (and storage) will know how much of a work that can be. Changing data structures may be equal to a complete rewrite - which would likely push towards switching to a different, more promising CPU such as 68k.
As a result it was a mandatory requirement for the 8086 to work with word data at odd addresses.
In addition it must be possible to read byte values from odd addresses without selecting the even part - not at least to read an 8 bit port at an odd address without selecting another at the corresponding even as well.
With that, it is no question if it could have saved space or not.
What Cost
With a 16-bit bus and the ability to read high and low byte independently, the whole hardware needed when reading is just two simple multiplexers to route the data:
- one to load the first byte read from low address delivered on D8..15 to a data latch holding the low value during the first read
- the second to do the the same for the second byte from the next address, provided on D0..D7
The first one must be present anyway to allow reading byte values from odd addresses - and of course from 8-bit ports at such.
For writing it's the same, just the other way around. So the additional hardware need is four 8-bit multiplexers. That's the very basic stuff of any data path. Make it a hundred transistors at most - not much compared to the 20-30k transistors an 8086 features. Even less as I would assume those connections exist anyway.
The Questions
What did this cost, in terms of performance and chip area?
Well, performance-wise it's of course the need to do two memory accesses instead of one, slowing that instruction down by four additional cycles. Chip-wise I would say none at all (see above).
compared to an alternative architecture that would have been the same except for unaligned access being a trap or undefined behavior?
Undefined is a bad idea and trap does for sure add more circuitry.
My first thought is that obviously a load/store circuit that doesn't need to take into account the possibility of unaligned access must clearly be simpler
Not really, as it still needs to support single-byte reads/writes to either half.
On the other hand, the instruction decoder needs to support unaligned access anyway.
Yes, but not how you think: The instruction stream is a byte stream, thus the prefetch logic does operate on byte level but the queue works on word level(*6).
Which points back to the conclusion that the chip could have been smaller and faster if it didn't support unaligned access.
No, the chip would neither notably smaller nor faster, beside the additional memory cycle that is.
In that case, every aligned access would have been at least one full clock cycle slower, just to support the possibility of unaligned access?
No, the additional memory cycle is only done if it's at an odd address. That would also be true if it was controlled by microprogram - which it wasn't.
*1 - Ken Shirriff just recently added a well written overview of he 80960 history, including many i432 references.
*2 - And all other microprocessor manufacturers.
*3 - GP computers were maybe more visible but puny in value compared to the many millions of CPUs sold for control application. Street lights, elevators and fridges still outnumber GP computers by far - or as
*4 - As long as it still fits inside the address space - which the 8086 duly expanded.
*5 - Just imagine the simple case of a structure with byte and word values mixed in between - oh, and have it having an odd length but being used in an array :))
*6 - Meaning that fetches from odd addresses, like after a jump, get done as a byte, while fetched words get split into bytes before being rearranged into words again - but now instruction aligned. It's one of the parts that made the later (!) creation of the 8088 easy (*7). Ken Shirriff goes into details when discussing prefetch on the 8086
*7 - Which Stephen Morse, the 8086's original creator, had not in mind. The 8088 was done by an independent team in Israel after the 8086 was finished.
