DOS ain't dead

Hi,
here's some interesting article where Linus comments on ongoing CPU changes
https://www.zdnet.com/article/linus-torvalds-on-ho...-changing-how-processor-interrupts-are-handled/
I'm not familiar with details and never programmed IDT so I'm just asking if it have some impact on our legacy DOS (and for someone Windows) systems that use pmode like JEMM, etc... If I understand well intel should have some control bit to switch between new and legacy behavior so there should not be problem until they remove that legacy mode...

---
DOS gives me freedom to unlimited HW access.

Hello RayeR,

> that use pmode like JEMM, etc... If I understand well intel should have
> some control bit to switch between new and legacy behavior so there should
> not be problem until they remove that legacy mode...

Yes, that seems to be true, at least for Intel's proposal. Apparently the new stuff will only kick in for 64-bit OSes; Section 3 says

> The FRED architecture is defined for use by a 64-bit operating system.
> Except where noted, changes to processor behavior and new instructions
> apply only in IA-32e mode (if IA32_EFER.LMA = 1) and not to legacy protected
> mode (or real-address mode).

I think the general idea is that Intel wants a CPU --- when handling a page fault, invalid instruction, etc. --- to avoid having to deal with an IDT in the first place. An IDT is a data structure in memory, so processing an interrupt through an IDT means a CPU needs to read from main memory, which is slow. If instead there are a bunch of (new) special registers in the CPU which say exactly how to handle an exception, then the CPU can read them very quickly, and start running the exception handler in no time.

I have not looked yet at what AMD is proposing, but it is reportedly less radical than Intel's, so I would guess it is also meant to be backward-compatible.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I think the general idea is that Intel wants a CPU --- when handling a page
> fault, invalid instruction, etc. --- to avoid having to deal with an IDT in
> the first place. An IDT is a data structure in memory, so processing an
> interrupt through an IDT means a CPU needs to read from main memory, which
> is slow.

OK, probably good idea. I would just note that the "slow" should not be so slow as I expect IDT is cached in CPU L1/L2 cache because it's often acessed so CPU shouldn't read from slow external SDRAM...

---
DOS gives me freedom to unlimited HW access.