X86 memory segmentation: Revision history

24 June 2025

• curprev 13:2613:26, 24 June 2025 Maxeto0910 talk contribs 24,004 bytes −1 no sentence undo Tags: Visual edit Mobile edit Mobile web edit Advanced mobile edit

10 June 2025

• curprev 06:4606:46, 10 June 2025 Guy Harris talk contribs 24,005 bytes 0 →Protected mode: Get rid of stray newline. undo

14 May 2025

• curprev 22:2922:29, 14 May 2025 Discospinster talk contribs m 24,005 bytes −1 Reverted edits by 2800:2242:0:C62:2548:CFF4:2CE:12A6 (talk) (HG) (3.4.13) undo Tags: Huggle Rollback
• curprev 22:2822:28, 14 May 2025 2800:2242:0:c62:2548:cff4:2ce:12a6 talk 24,006 bytes 0 →80286 protected mode undo Tag: Reverted
• curprev 22:2422:24, 14 May 2025 2800:2242:0:c62:2548:cff4:2ce:12a6 talk 24,006 bytes +1 →Real mode undo Tag: Reverted

3 May 2025

• curprev 19:5319:53, 3 May 2025 Alexander Davronov talk contribs 24,005 bytes +7 "system programmer" undo Tag: Visual edit

15 April 2025

• curprev 21:2321:23, 15 April 2025 AnomieBOT talk contribs m 23,998 bytes +16 Dating maintenance tags: {{Fact}} undo
• curprev 19:2219:22, 15 April 2025 100.34.18.149 talk 23,982 bytes +57 →Practices: Improvement: detail. undo
• curprev 19:2119:21, 15 April 2025 100.34.18.149 talk 23,925 bytes +8 →Practices: Citation needed for the exception. Which instruction that uses DS by default cannot take an override prefix? Are these only 80286 or later CPU instruction? undo
• curprev 19:1519:15, 15 April 2025 100.34.18.149 talk 23,917 bytes +20 →80386 protected mode: Copy edit (self-explanatory). undo
• curprev 19:1319:13, 15 April 2025 100.34.18.149 talk 23,897 bytes +57 →80286 protected mode: Correection. The 80286 itself cannot be reset by a triple fault. A triple fault puts the 286 into a state called "shutdown". External hardware in the IBM AT (and clones) detects the shutdown state signalled on the CPU status output lines and then issues a reset signal to the CPU, getting it out of shutdown and back into Real Mode. undo
• curprev 19:0619:06, 15 April 2025 100.34.18.149 talk 23,840 bytes +56 →80286 protected mode: Copy edit; mutliple small changes, including language agreement in number. Also added a clarifying detail. By the way, A20 gate or not, the IBM AT did /not/ by any means have "full" backward software compatibility; lots things in the hardware were changed incompatibly. undo
• curprev 19:0019:00, 15 April 2025 100.34.18.149 talk 23,784 bytes +73 →80286 protected mode: Clarified what shift value is being referred to. undo
• curprev 18:5718:57, 15 April 2025 100.34.18.149 talk 23,711 bytes +28 →End-of-address-space quirkiness: Clarified: It is actually not complex to use separate segments for program code, data, and the stack, or to store separate hetereogeneous data in multiple 64 KB segments. What becomes quite complex is handling a single data object larger than 64 KB. undo
• curprev 18:5318:53, 15 April 2025 100.34.18.149 talk 23,683 bytes +13 →End-of-address-space quirkiness: --Missed one. undo
• curprev 18:5218:52, 15 April 2025 100.34.18.149 talk 23,670 bytes +19 →End-of-address-space quirkiness: This applies equally to 8086 and 8088 CPUs. undo
• curprev 18:5018:50, 15 April 2025 100.34.18.149 talk 23,651 bytes 0 →End-of-address space quirkiness: copy edit/language correction: this not referring to a space that is about the "end of address", it is quirkiness about the "end of address space". undo
• curprev 18:4518:45, 15 April 2025 100.34.18.149 talk 23,651 bytes +56 →Real mode: Cleaned up math example with non-breaking spaces so that the binary numbers will not break and wrap. (This probably really ought to be formatted as a table or something like that.) undo
• curprev 18:3518:35, 15 April 2025 100.34.18.149 talk 23,595 bytes +132 Clarification: BP does not have to refer to the stack; because it is designed to most of the time, it defaults to SS, but that can be overridden, and to imply otherwise would misinform the reader. The point is, besides pushes and pops, "data references to the stack" are whatever data references the programmer addresses to the stack; there are no stack-specific instructions for such references that are not pushes and pops. undo
• curprev 18:2418:24, 15 April 2025 100.34.18.149 talk 23,463 bytes +184 corrections: ES is not overrideable as string destination, and this it is a second exception to " All other references to data use the data segment." undo

9 March 2025

• curprev 15:2315:23, 9 March 2025 ReadOnlyAccount talk contribs 23,279 bytes +9 →End-of-address space quirkiness undo
• curprev 06:0506:05, 9 March 2025 ReadOnlyAccount talk contribs m 23,270 bytes +1 →End-of-address space quirkiness undo
• curprev 06:0406:04, 9 March 2025 ReadOnlyAccount talk contribs m 23,269 bytes −1 →End-of-address space quirkiness undo
• curprev 06:0306:03, 9 March 2025 ReadOnlyAccount talk contribs 23,270 bytes +69 →End-of-address space quirkiness undo
• curprev 01:2001:20, 9 March 2025 ReadOnlyAccount talk contribs 23,201 bytes 0 →End-of-address space quirkiness undo
• curprev 01:1601:16, 9 March 2025 ReadOnlyAccount talk contribs 23,201 bytes +9 →End-of-address space quirkiness undo
• curprev 01:1601:16, 9 March 2025 ReadOnlyAccount talk contribs 23,192 bytes +84 →End-of-address space quirkiness undo
• curprev 01:1501:15, 9 March 2025 ReadOnlyAccount talk contribs 23,108 bytes +66 →Real mode: Again I'm uncertain about this edit too, so feel free to revert it, but again, please think about why I did this and what I'm trying to do now – and maybe you have a better idea? undo
• curprev 01:0401:04, 9 March 2025 ReadOnlyAccount talk contribs 23,042 bytes +2 →Real mode: separate undo
• curprev 00:5900:59, 9 March 2025 ReadOnlyAccount talk contribs 23,040 bytes +6 →Real mode: nicer undo
• curprev 00:5800:58, 9 March 2025 ReadOnlyAccount talk contribs 23,034 bytes +52 →Real mode: I'm really uncertain about this edit, so feel very free to revert it, but please think about why I did this and what I'm trying to do here – maybe you have a better idea? undo
• curprev 00:1600:16, 9 March 2025 ReadOnlyAccount talk contribs 22,982 bytes +13 →Real mode: That's only an example. undo

6 March 2025

• curprev 12:1212:12, 6 March 2025 Cedar101 talk contribs m 22,969 bytes 0 →Practices: {{codett}} undo
• curprev 12:1112:11, 6 March 2025 Cedar101 talk contribs m 22,969 bytes +16 →Practices: {{codett}} undo

17 February 2025

• curprev 00:2300:23, 17 February 2025 ReadOnlyAccount talk contribs 22,953 bytes +37 →Real mode: specify, so as to not contradict what's below undo

16 February 2025

• curprev 23:4823:48, 16 February 2025 ReadOnlyAccount talk contribs 22,916 bytes +18 →Real mode undo
• curprev 23:4023:40, 16 February 2025 ReadOnlyAccount talk contribs 22,898 bytes 0 →Real mode: moving on up undo
• curprev 23:1723:17, 16 February 2025 ReadOnlyAccount talk contribs 22,898 bytes +190 →Real mode: I feel half-bad elaborating on the slightly wacky idea that's already in that paragraph in the text, but, well, we'll see if this takes and makes sense to people. undo
• curprev 17:3317:33, 16 February 2025 ReadOnlyAccount talk contribs 22,708 bytes −39 →Real mode: Let's go ahead and confine the idea of treating real mode memory segments as less-than-64K to those in-the-weeds paragraphs further below (where the multiples-of-16b stuff is already mentioned). Mentioning less-than-64K here was based on Joh's bad misunderstanding, because either wrapping around or crossing the 1MB threshold is of course exactly what happens. So this is me reverting this https://en.wikipedia.org/w/index.php?title=X86_memory_segmentation&diff=prev&oldid=724199929 undo
• curprev 17:1317:13, 16 February 2025 ReadOnlyAccount talk contribs 22,747 bytes +66 Noted. undo
• curprev 17:0917:09, 16 February 2025 ReadOnlyAccount talk contribs 22,681 bytes 0 →Real mode undo
• curprev 17:0217:02, 16 February 2025 ReadOnlyAccount talk contribs 22,681 bytes 0 →Real mode undo
• curprev 15:1915:19, 16 February 2025 ReadOnlyAccount talk contribs 22,681 bytes +686 WP:BOLDly go... towards a raison d'être undo
• curprev 10:1310:13, 16 February 2025 ReadOnlyAccount talk contribs 21,995 bytes +9 →80286 protected mode undo
• curprev 10:0510:05, 16 February 2025 ReadOnlyAccount talk contribs 21,986 bytes +22 →Real mode: tone down, deconflict; was self-contradictory. I'm still not happy with this. I have now realised (d'oh!) that the edit summary of the Joh edit that sucked me in contains a glaring misunderstanding, at odds with the A20, etc. stuff further down below. Also, what was deduced from that misunderstanding was arguably OR. I will likely revisit. This isn't even my final form. undo
• curprev 00:1500:15, 16 February 2025 ReadOnlyAccount talk contribs 21,964 bytes −21 →Real mode: shorter undo
• curprev 00:0800:08, 16 February 2025 ReadOnlyAccount talk contribs 21,985 bytes +265 →Real mode: It still wasn't quite clear, I feel. Also, stepping on memory is possible within the same segment (be it the technically maximum size of 64K or smaller) AND by involving any other segment. undo

14 February 2025

• curprev 23:1023:10, 14 February 2025 ReadOnlyAccount talk contribs 21,720 bytes +103 →Real mode: OMG, turns out, per en.wikipedia.org/w/index.php?title=X86_memory_segmentation&diff=prev&oldid=441344024 the 1 byte was NOT a typo. So that's where Joh got it from? I CAN actually understand what OR made the OP think 1 byte, but that's not a real (mode) segment size, it's sectionable! Just bc you're not USING all 16 bytes doesn't mean the segment wasn't 16 bytes. If every "1-byte segment" MUST be followed by a 15-byte gap before the next starts, THAT'S ACTUALLY A 16-BYTE SEGMENT! undo
• curprev 20:0920:09, 14 February 2025 ReadOnlyAccount talk contribs 21,617 bytes −6 →Real mode: Since it's plural both times, saying bytes twice seems redundant. Also, post-script to previous edit summary: Upon further consideration, I actually think that erroneous "1" (instead of "16") may quite possibly also just have been a simple typo. undo
• curprev 14:5914:59, 14 February 2025 ReadOnlyAccount talk contribs 21,623 bytes +4 →Real mode: 16 bytes, not 1. The error was introduced here: https://en.wikipedia.org/w/index.php?title=X86_memory_segmentation&diff=prev&oldid=724199929 ; cf. the errant editor's own edit summary – regarding which: The editor was correct to say a segment is not always 64K, but the segment from 0xFFFF0 through 0xFFFFF is 16 bytes in size, which is the x86 architecture's minimum. Also, use "through", not "up to". The latter is basically an off-by-one error. undo