The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned access being a trap or undefined behavior?
To be clear, I'm not talking about the dynamic behavior of code. On the actual 8086, access was still faster if the pointer did happen to be even. I'm asking, suppose all your pointers for word access were actually even, how much bigger and slower was the chip made by having to support the possibility that some of them could have been odd?
My first thought is that obviously a load/store circuit that doesn't need to take into account the possibility of unaligned access (and be ready to do the complicated fallback routine of two accesses and splicing the parts together) must clearly be simpler, therefore smaller and faster, then one does need to take into account this possibility.
On the other hand, the instruction decoder needs to support unaligned access anyway.
On the third hand, that might not be relevant here; the instruction decoder is probably a completely separate circuit that doesn't share parts with the data load/store circuitry.
Which points back to the conclusion that the chip could have been smaller and faster if it didn't support unaligned access.
Then again, maybe the test for the fallback case, wasn't a bottleneck in cycle time? In that case, maybe it only cost chip area?
Or maybe it was an extra microcode stage? In that case, every aligned access would have been at least one full clock cycle slower, just to support the possibility of unaligned access?
