Post B6mBPEX73jbJxtVEIK by joe@f.duriansoftware.com
 (DIR) More posts by joe@f.duriansoftware.com
 (DIR) Post #B6lLKkfewtIqZg2fbs by joe@f.duriansoftware.com
       0 likes, 1 repeats
       
       I was reading about "unreal mode" on the x86, as one does https://www.os2museum.com/wp/a-brief-history-of-unreal-mode/I knew there are fundamental architectural problems with using a >64k code segment under real mode, since the processor will only save the 16-bit CS:IP, but michal's post hints at problems with >64k stacks as well. i can foresee problems within a DOS environment (OS routines using 16-bit arithmetic instructions on SP), but from bare metal, are there hardware-level problems with large stacks in real mode as well?
       
 (DIR) Post #B6mBPEX73jbJxtVEIK by joe@f.duriansoftware.com
       0 likes, 0 repeats
       
       we have the 386 microcode dump now, but that alone doesn't fully reveal the details. looks like `eSP` is the thing that gets updated, but i didn't see notes on when exactly eSP refers to SP or ESP. i would guess it comes from the current SS, since a 16-bit code segment with >64K stack segment would be a weird-but-valid protected mode environment
       
 (DIR) Post #B6mBPEn46QMSlMxy9w by joe@f.duriansoftware.com
       0 likes, 0 repeats
       
       the 386SX programmer's reference manual seems to confirm this. i should try it on the real 386 in my FM TOWNS
       
 (DIR) Post #B6mBPEz7Nc0DMkbawi by djsumdog@djsumdog.com
       0 likes, 0 repeats
       
       ... I can only imagine horrors under the surface in the 32/64 multi-lib era
       
 (DIR) Post #B6mBt49KEJoKRqbM3s by joe@f.duriansoftware.com
       0 likes, 0 repeats
       
       @djsumdog 32- and 64-bit code coexisting is relatively rational and well-documented, all things considered. "unreal mode" is a complete accident of the 386 implementation that turned into a trick people depend on