Talk:X86 memory segmentation

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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