[HN Gopher] 80386 Memory Pipeline
___________________________________________________________________
80386 Memory Pipeline
Author : wicket
Score : 74 points
Date : 2026-04-14 16:00 UTC (4 days ago)
(HTM) web link (nand2mario.github.io)
(TXT) w3m dump (nand2mario.github.io)
| andyjohnson0 wrote:
| Interesting article. I learned some things.
|
| How hard would it be for Mr Github to add rss/atom feeds, I
| wonder?
| mrlonglong wrote:
| Voodoo mode is the ultimate test. Imagine having access to 4GB of
| memory from real mode.
| jmmv wrote:
| Shameless plug for my
| https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i...
| article from a couple of years ago. You'll find a deep dive on
| unreal mode (I just learned it's also known as "vodoo mode")
| and some hands-on code to play with it ;-P
| bombcar wrote:
| I want vooDOS 5.0 which is 32 bit clean :)
| mrlonglong wrote:
| There are things like DOS4GW that you can use as loaders.
| vardump wrote:
| Most people called it unreal mode.
|
| https://en.wikipedia.org/wiki/Unreal_mode
| blueybingo wrote:
| wasn't this basically the consensus among numerical analysts like
| 20 years ago? i remeber reading similar arguments in goldberg's
| paper and various game dev forums circa 2005, so genuinely
| curious what keeps making this idea feel "new" to each generation
| of programmers who rediscovers it
| curiousObject wrote:
| I think you're missing the point. This person is implementing
| various CPU cores on FPGA. The insights they can share from
| that complex process are sometimes interesting, because they
| are looking at the system from a new angle.
|
| https://nand2mario.github.io/projects/
| rep_lodsb wrote:
| OP probably meant to post in another thread:
| https://news.ycombinator.com/item?id=47767398
| rep_lodsb wrote:
| Again a very interesting look at how this chip works internally!
|
| I've decoded the entry point PLA of the 80286 (not the actual
| microcode though). It also has separate entries for real and
| protected mode, but _only_ for segment loads from a general
| purpose register, HLT, and for those opcodes that aren 't allowed
| in real mode like ARPL.
|
| Loading a segment register from memory on the 286 uses the _same_
| microcode in both modes, as does everything else that would
| certainly have to act differently, like jump /call far. That was
| a bit surprising, since it would have to decide at run time which
| mode it's in. Is this the same on the 386?
|
| Tested on my 286 machine what happens when opcodes are decoded
| while in real mode but executed after PE is set: Segment load
| from memory works (using protected mode semantics), whereas the
| load from register only changes the visible selector and nothing
| else. The base in the descriptor cache keeps whatever was set
| there before -- I assume on the 386, SBRM would update the base
| the same way it does in real mode in that situation, because it's
| also used for V86 mode there. Illegal-in-real-mode instructions
| trap, but do so correctly using the protected mode IDT.
|
| Also seems like executing three pre-decoded instructions without
| a jump after setting PE causes a triple fault for some reason.
| bell-cot wrote:
| > Also seems like executing three pre-decoded instructions
| without a jump after setting PE causes a triple fault for some
| reason.
|
| It's been a while, but I recall Intel documenting that a jump
| was required almost immediately after setting PE. Probably
| because documenting "you must soon jump" was easy. Vs. handling
| the complexities of decoded-real/executed-PE - and documenting
| how that worked - would have been a giant PITA.
|
| The two-instruction grace period was to let you load a couple
| segment or descriptor table registers or something, which were
| kinda needed for the jump. And that triple fault - if you
| failed to jump in time - sounds right in line with Intel's
| "when in doubt, fault or halt" philosophy for the 286.
___________________________________________________________________
(page generated 2026-04-18 23:00 UTC)