Talk:X86 memory segmentation

message: “The Linux kernel sets up only 4 segments…” Really? Doesn’t Linux use TSS segments as well? And some others? Understanding the Linux Kernel (2nd edition) says so about the 2.4 kernel. Don’t know whether it’s true for the 2.6 kernel as well…
Linux only uses 4 memory segments.  Task State Segments are different and Linux only uses 1 of them.  A few other miscellaneous segments (for APIC stuff I believe) are used, but the kernel and userspace only use the 4 segments listed.  I suppose that could be made a bit more clear... David.kaplan 16:04, 30 September 2006 (UTC)
thread_title:  Segments in Linux 

message: It seems a company called VAutomation (now ARC) has been selling "Turbo186" cores that are mostly 80186 compatible but compute addresses as linear = (segment << 8) + offset, rather than linear = (segment << 4) + offset; this raises the granularity of segment starting addresses to 256 bytes and allows access to 16 MiB of memory in real mode.  Such processors would of course go in an embedded system rather than in a PC.  Have other manufacturers had similar products?  Can this be added to the article?  213.216.199.53 14:25, 18 July 2007 (UTC)
replies: text: I collected some references at Talk:Intel 8086#Embedded processors with 256-byte paragraphs.  85.23.32.64 (talk) 15:56, 13 July 2009 (UTC)
thread_title:  256-byte granularity in Turbo186 

message: This page claims:
:x86 memory segmentation refers to the implementation of memory segmentation on the x86 architecture.
But the memory segmentation page states quite the opposite, namely:
:This usage should not be confused with that of the memory segments used by early x86 processors such as the Intel 8086 and Intel 8088, as they did not provide any protection; segmentation in the Intel 80286 and later provided protection.
I see some major contradiction or at least the need to clarify and pinpoint some detail. --Blazar.writeto() 08:09, 14 August 2008 (UTC)
replies: text: Memory segmentation no longer says "This usage should not be confused with that of the memory segments used by early x86 processors..." - it now says "The memory segmentation used by early x86 processors, beginning with the Intel 8086, does not provide any protection.".  Guy Harris (talk) 21:14, 25 March 2021 (UTC)
thread_title:  Major contradiction 

message: :For instance, the segmented address 6EFh:1234h has a segment selector of 6EFh, which corresponds to the 20-bit linear address 6EF0h.
For those not familiar with the topic, 6EF0h looks like 16 bit wide number. Something like A6EFh and A6EF0h will look more clear.--Yegorius (talk) 15:57, 4 January 2009 (UTC)
thread_title:  Real mode addressing example 

message: "(this is true for 64bit mode as well, but beyond the scope of discussion)"
No it isn't! This is pertinent information to put here.  —Preceding unsigned comment added by 216.107.215.226 (talk) 21:37, 22 November 2010 (UTC)
thread_title:  "Beyond the Scope" 

message: I edited the part about segment registers in x86-64 environments to be more readable and accurate. However, there are very few references for this information, most of it being WP:OR. What I can say is the following:
* Linux uses the FS segment on x86 and the GS segment on x86-64 to point to per-CPU data. My source is arch/x86/include/asm/percpu.h.
* Windows x64 (64-bit) uses the GS segment to point to the TEB. This doesn't seem to be properly documented anywhere, but it can be 'trivially' proven by reverse-engineering some core DLLs. In a similar way, one can determine that Windows x86 (32-bit) uses the FS segment to point to the TEB.
I'd like to see proper referencing for this information in this article, but unfortunately I can't provide it myself. --87.251.51.88 (talk) 13:03, 9 April 2012 (UTC)
thread_title:  Usage in x86-64 

message: The article states that in 286 protected mode (and the later 32-bit protected mode), the first 1MB of memory cannot be accessed.  This seems wrong to me.  Rather than just remove it, can anyone confirm one way or the other? -- Malvineous (talk) 03:46, 21 November 2015 (UTC)
thread_title:  286 protected mode and <1MB 

message: The current text says "it still necessitated dividing memory into 64k segments like was done in real mode. This limitation can be worked around on 32-bit CPUs which permit the use of memory pointers greater than 64k in size, however as the base addresses remain 24-bit, the maximum segment size that can be created is 16MB"
I am no 286 guru, but, in reading the rest of the information, it sounds like the limitation of the segment size is due to the Segment Limit field being only 24 bits long https://en.wikipedia.org/wiki/Segment_descriptor. The fact that the base address is 24 bits long does not sound like a reason to limit the segment size, only their starting address.
Can someone confirm? JayWH2 (talk) 17:08, 13 February 2016 (UTC)
thread_title:  286 protected mode and maximum segment size 

message: In the section entitled "Later developments", what does SWAPGS stand for?  — Preceding unsigned comment added by 95.147.5.140 (talk) 18:35, 16 August 2019 (UTC)
thread_title:  What does SWAPGS stand for 

message: For the chunk showing the calculation of the address between the second and third paragraphs of text in section "Real mode", the sequences of binary numbers are wrapping on my display (and wrapping at different points), making the whole look nonsensical. I'm not sure if this is caused by some error in the markup used, or by the image (Overlapping_realmode_segments.svg) appearing to its right and thus narrowing the available window, and have no clue how to fix it. Hv (talk) 13:45, 8 September 2022 (UTC)
replies: text: just fixed that, was bugging me too Tetraxile (talk) 12:16, 12 April 2023 (UTC)
replies: text: Super, thank you. Hv (talk) 11:56, 15 April 2023 (UTC)
thread_title:  Display problems for calculation