4 ms·

The mistake was with the fact, that 8086 has 64kB-16B worth of user visible memory addresses that are beyond what the harware could actually address due to widt

by dfox 9y ago

The mistake was with the fact, that 8086 has 64kB-16B worth of user visible memory addresses that are beyond what the harware could actually address due to width of the physical address bus and thus got aliased to the other end of address space. People say that there was software that depended on this behavior, but I can't see any sane reason why somebody would write something like that (given how the address layout of PC looks like the only sane application of this aliasing is in the early initialization BIOS code, which obviously had to be significantly rewritten for AT) Edit: the reason why 486 and later CPUs contain the A20M logic internally has nothing to do with "memory mapping". 486 has on chip cache which has to know, whether this memory region is aliased or not. Additional effect of this logic being in the CPU is that it can be controlled by writes into MSRs, which are significantly faster than sending commands into KBC which controlled this thing on AT. (Also, in vm86 mode this compatibility hack could be implemented by MMU without dedicated hardware cludges, which is what essentially all DOS XMS managers do)

ajross 9y ago
You're arguing semantics. Pulling the cache on-chip means that the memory bus and its mapping logic needs to be on-chip too, because it sits beneath the cache. We're saying exactly the same thing. (And FWIW: the mistake Intel made was that those accesses were legal on an 8086. They should have been an exception condition, which would have avoided this problem by making the 286 behavior a proper superset)
- dfox 9y ago
  I know we are saying ecactly the same thing, but somebody else who reads this threads might not, so the successive clarifications are useful :) In hindsight, making accesses beyond the end of physical memory on 8086 an exception is nice solution. But I think that more useful solution would be different design of the 8086 pseudo-segmentation that would make such linear adresses unrepresentable on the user level. On the other hand whether this would be good idea depends on whether you view another horrible cludge (ie. HMA/UMB and potentially also usage of that as EMS window or bounce buffer) as useful. Edit: as for the memory attached to processor behaving sanely it is interesting to look at Alpha which expects that memory is memory and could be write back cached. With one small and significant exception: the region on which ISA VGA would exist is hardwired to be uncacheable.

by dfox 9y ago

ajross 9y ago

You're arguing semantics. Pulling the cache on-chip means that the memory bus and its mapping logic needs to be on-chip too, because it sits beneath the cache. We're saying exactly the same thing. (And FWIW: the mistake Intel made was that those accesses were legal on an 8086. They should have been an exception condition, which would have avoided this problem by making the 286 behavior a proper superset)

dfox 9y ago
I know we are saying ecactly the same thing, but somebody else who reads this threads might not, so the successive clarifications are useful :) In hindsight, making accesses beyond the end of physical memory on 8086 an exception is nice solution. But I think that more useful solution would be different design of the 8086 pseudo-segmentation that would make such linear adresses unrepresentable on the user level. On the other hand whether this would be good idea depends on whether you view another horrible cludge (ie. HMA/UMB and potentially also usage of that as EMS window or bounce buffer) as useful. Edit: as for the memory attached to processor behaving sanely it is interesting to look at Alpha which expects that memory is memory and could be write back cached. With one small and significant exception: the region on which ISA VGA would exist is hardwired to be uncacheable.