Timeline for Why did x86 support self-modifying code without explicit flushes in the 80s and 90s?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 1 at 1:02 | comment | added | Raffzahn | @Barmar Except that's the whole point. Compatibility means that a new generation (like one introducing cache and cache instructions) has to execute code with the same effect as previous generation. This of course includes the code loader - or how should DOS, written for bare bone 8088 know how to flush a 486 or pentium cache? | |
| May 1 at 0:06 | comment | added | Barmar | The question isn't why self-modifying code is allowed. The question is why it doesn't require an explicit cache flush after modifying the code. Surely the code loader could do that easily. | |
| S Apr 28 at 22:08 | history | edited | Raffzahn | CC BY-SA 4.0 | typo in footnote numbering; it -> is; fill sentence to hit 6 chars |
| S Apr 28 at 22:08 | history | suggested | Jim J. Jewett | CC BY-SA 4.0 | typo in footnote numbering; it -> is; fill sentence to hit 6 chars |
| Apr 28 at 20:42 | review | Suggested edits | |||
| S Apr 28 at 22:08 | |||||
| Dec 3, 2022 at 23:58 | history | edited | Raffzahn | CC BY-SA 4.0 | added 671 characters in body |
| Dec 3, 2022 at 23:38 | comment | added | occipita | Probably the most commonly-used example of self-modifying/generated code on 16-bit PCs was Windows' BitBlt API, used for drawing images and copying areas of screen around, which used code generated on the stack segment to perform the requested drawing operations. See Raymond Chen's description here: devblogs.microsoft.com/oldnewthing/20180209-00/?p=97995 | |
| Dec 3, 2022 at 15:40 | history | edited | Raffzahn | CC BY-SA 4.0 | added 2547 characters in body |
| Dec 3, 2022 at 15:32 | comment | added | Raffzahn | @NateEldredge Jup, that's the usual case of generated code - thanks for the reminder. | |
| Dec 3, 2022 at 7:33 | comment | added | supercat | @NateEldredge: Another alternative approach for implementing INT would be to push the flags and desired return address, followed by the contents of the interrupt vector to use, and then perform a far return. | |
| Dec 3, 2022 at 4:35 | comment | added | Nate Eldredge | One that I remember is Turbo C++'s int86() function. Since the INT instruction takes an immediate, but int86 wants the interrupt number as a runtime argument, they use self-modifying code. The alternative is to waste some 1024 bytes by coding out all 256 possibilities and jumping to the right one. | |
| Dec 3, 2022 at 4:14 | history | answered | Raffzahn | CC BY-SA 4.0 |