Talk:x86 memory segmentation

Untitled

Segments in Real mode on the Intel x86 architecture overlapped, which is poor design.

I removed this because Wikipedia should not pronounce judgement on what's good and what's bad design. It was tempting to leave it in with the weasel phrase "Some feel that...", since I do feel it's poor design, but I resisted. - furrykef (Talk at me) 02:42, 24 October 2005 (UTC)

World may eventually come back to Data Execution Prevention anyway :~)

[segmentation scheme is desperately needed by embedded processors today] 150.101.166.15 (talk) 10:31, 1 January 2008 (UTC)

I presume you meant 386's segmentation scheme is desperately needed by embedded processors today; the link you provided didn't work (the syntax for external links isn't what you appear to have thought it was). What you presumably meant to say is needed is some way of preventing writable regions of memory from being executable; segmentation is one way of providing that, but not the only way of providing that - the NX bit is another way of providing that (and some non-x86 architectures already implement such a mechanism, as the NX bit page indicates). Guy Harris (talk) 11:02, 1 January 2008 (UTC)

Segments in Linux

“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)

Overlapping addresses

A single linear address can be mapped to many segmented addresses. For instance, the linear address above (0x08124) can have the segmented addresses 0x6EF0:0x1234, 0x0812:0x0004 and 0x0000:0x8124 (and many more). This could be confusing to programers accustomed to unique addressing schemes.

What was the interest in allowing such overlaps? --Abdull 13:19, 7 July 2007 (UTC)

The data sheet for "8086 16-Bit HMOS Microprocessor" in Intel Microsystem Components Handbook 1986 mentions that segments can be "up to 64K bytes each" and are "relocatable". It thus seems the intention was that each byte of memory would normally be addressed with only one segment:offset address. The 16-byte granularity of segment starting addresses then allows the variable-size segments to be placed close to each other, thereby taking all advantage of available memory. If the granularity were 64K bytes, then instead of dividing 128K RAM into e.g. 48K + 48K + 32K segments, a programmer would have to use 64K + 64K and split the 32K area into two pieces, resulting in more segment register loads and more complex code.

MS-DOS makes use of the relocatability of segmented programs. It keeps track of free memory in 16-byte units, loads a program into a 16-byte-aligned address, and then adjusts the segment addresses within the program based on the relocation table in the EXE file. Near pointers (offset without a segment) in the program not be relocated at all. (A more advanced operating system might relocate each segment individually, and thus be able to split a multi-segment program across fragments of free memory; but in the single-tasking MS-DOS, free memory is mostly contiguous.)

Unlike in protected mode, the processor does not know the sizes of segments and cannot detect out-of-bound accesses. This allows for efficient implementation of "huge" arrays of more than 64K in size, as long as each element (e.g. a structure) is at most 65521 bytes long: the code can "normalize" the address of any element to a segment:offset address where the offset is between 0 and 15, and then access the contents of that element without risk of overflowing the offset part. Of course, programs that make use of segment arithmetic cannot run directly in protected mode. 213.216.199.53 14:14, 18 July 2007 (UTC)

256-byte granularity in Turbo186

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)

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)

Major contradiction

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)

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)

Real mode addressing example

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)

"Beyond the Scope"

"(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)

Usage in x86-64

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)

286 protected mode and <1MB

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)

I don't see this mentioned in the 286 protected mode section any more, so I guess it got removed. JayWH2 (talk) 16:54, 13 February 2016 (UTC)

286 protected mode and maximum segment size

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 . 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)

References

What does SWAPGS stand for

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)

Display problems for calculation

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)

just fixed that, was bugging me too Tetraxile (talk) 12:16, 12 April 2023 (UTC)

Super, thank you. Hv (talk) 11:56, 15 April 2023 (UTC)