3 ms·

I really can't grasp the "undocumented mode" term. I believe It was created on request.

dfox 9y ago
That is pretty much standard term for processor features that are not supported by Intel. The main selling point of the whole Intel's x86 platform is that when something is supported and documented it will either behave the same way on newewr processors or newer processors would include some mechanism to emulate the old behavior. Intel tends to go especially overboard with this approach and even support feature combinations that are not useful in any way. Recent example is that original AMD's x86_64 CPUs did not support certain descriptor formats in long mode and didn't support x87 FPU ISA for 64b code. Intel's EMT64 supports both of these things. Usefulnes of first is somewhat questionable as only real user of that is dosemu, another would be if somebody would want to modify some Concurrent DOS/FlexOS derived OS to be 64b aware (there actually might be some small bussiness case for doing so). Microsoft solved this by droping support for 16b and DOS applications in 64b builds. And for the second limitation it is pretty obvious that there cannot be any code that would be broken by that. Older examples are the whole A20M# business and then there is LOADALL, which was never officially documented, has three diferrent encodings and behaviors depending on CPU generation but got used by Microsoft and thus the 386 encoding and behavior is somewhat semi-documented and semi-supported even 30 years later.
- ajross 9y ago
  Just to clarify: the A20 stuff was an IBM PC/AT feature in the chipset of the original machine, not a CPU thing. It was actually a response to an Intel mistake in backward compatibility between the 8086 and 286 (real mode segments that pointed "beyond" the first 1MB would wrap around on the original processor but hit the second megabyte on the 286). But when the memory mapping went on-chip in later devices, it needed to be part of the CPU core for compatibility with software written to work on the AT.
  - 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.

dfox 9y ago

That is pretty much standard term for processor features that are not supported by Intel. The main selling point of the whole Intel's x86 platform is that when something is supported and documented it will either behave the same way on newewr processors or newer processors would include some mechanism to emulate the old behavior. Intel tends to go especially overboard with this approach and even support feature combinations that are not useful in any way. Recent example is that original AMD's x86_64 CPUs did not support certain descriptor formats in long mode and didn't support x87 FPU ISA for 64b code. Intel's EMT64 supports both of these things. Usefulnes of first is somewhat questionable as only real user of that is dosemu, another would be if somebody would want to modify some Concurrent DOS/FlexOS derived OS to be 64b aware (there actually might be some small bussiness case for doing so). Microsoft solved this by droping support for 16b and DOS applications in 64b builds. And for the second limitation it is pretty obvious that there cannot be any code that would be broken by that. Older examples are the whole A20M# business and then there is LOADALL, which was never officially documented, has three diferrent encodings and behaviors depending on CPU generation but got used by Microsoft and thus the 386 encoding and behavior is somewhat semi-documented and semi-supported even 30 years later.

ajross 9y ago
Just to clarify: the A20 stuff was an IBM PC/AT feature in the chipset of the original machine, not a CPU thing. It was actually a response to an Intel mistake in backward compatibility between the 8086 and 286 (real mode segments that pointed "beyond" the first 1MB would wrap around on the original processor but hit the second megabyte on the 286). But when the memory mapping went on-chip in later devices, it needed to be part of the CPU core for compatibility with software written to work on the AT.
- 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.