Talk:Memory segmentation

Paging, segmentation, and protection

Afaik, paging isn't another way to ensure page protection; in fact, I believed that segmentation was built upon paging just to address a lack of the latter.

See for example Tanenbaum A., "Modern Operating Systems", 2nd edition, §4.8 - fig. 4.37.

No. There exist processors that offer segmentation without paging (e.g., the Burroughs large systems) and thus offer only segment-level protection, processors that offer paging without segmentation (e.g., several RISC processors such as MIPS processors) and that use protection bits in the page table to provide protection, and processors that offer both paging and segmentation and either use only segment protections or segment protections and per-page protections to provide protection. Guy Harris 04:12, 13 November 2007 (UTC)

Merge?

I believe this article should be merged with Memory segment. They are about essentially the same thing. Strake 21:29, 9 August 2006 (UTC)

Agreed, or maybe memory segment should be merged here. I wrote most of the memory segment article because at the time, that seemed like the logical place. But here might make sense. Propose the merge David.kaplan 02:14, 22 October 2006 (UTC)

Currently, memory segment is an article about segmentation in x86 processors, not about segmentation in general. This page shouldn't be merged with it; we need at least one page to describe segmentation in general, without incorporating a bunch of x86 stuff that might lead people to think x86 segmentation (whether real or protected mode) is the be-all and end-all of segmentation. (Perhaps memory segment should be renamed in such a way as to make it clearer that it's x86-specific.) Guy Harris 04:06, 13 November 2007 (UTC)

Looking for the meaning of the order or command ls I found that it is defined elsewhere as "short for list" and in Wikipedia as: "Its name derives from a similar command list segments in Multics, a system in which memory segments and files were synonyms." So I wonder if the origin is "list segments" and not the improbable "list". Could someone please confirm whether ls actually originates in "list segments"? I am after this because it is so much simple to remember the commands if one knows where they come from originally. Because of this I think that memory segment is a concept clearly different from segmentation and should be explained separately. --FelipeTD (talk) 19:30, 12 July 2009 (UTC)

Memory segment now redirects to memory segmentation, and there's an x86 memory segmentation page for all the x86-specific stuff. Guy Harris (talk) 07:55, 18 November 2010 (UTC)

Segmentation and protection

It's worth noting that in several implementations of segmented VM, "protection" (when present at all) was not applied to the segment but rather the segment pointer. On both the Burroughs and IBM S/38 systems authorities were checked when the segment pointer was loaded. I vaguely recall that in the Burroughs case some of the protections were loaded into hardware registers, for later checking against memory accesses, but in the case of the S/38 no authority information was preserved after loading the pointer -- rather the reason for loading the pointer (read/write/execute/etc) was checked against the authority bits in the pointer, and an error generated if the pointer could not be loaded for that reason.

In spite of this "weakness", the S/38 OS was quite secure. drh (talk) 22:35, 3 January 2013 (UTC)

Confusion about memory address segments and linker's segments may not exist

The article’s title "memory segmentation" suggest that it is a matter of memory addressing. But such things as "code segment" (in an object file) do not require that segment registers actually had any use. Incnis Mrsi (talk) 20:16, 28 January 2013 (UTC)

Sounds right to me, maybe some of the discussion of object files should be deleted or moved. Segments (or groups) in an object can support memory segmentation if it exists. Peter Flass (talk) 20:31, 28 January 2013 (UTC)

But what to do with Code segment (edit | talk | history | links | watch | logs)/Text segment (edit | talk | history | links | watch | logs)? In one hand, the term possesses the same ambiguity between linker’s segments and CPU segments. In another hand, the information at CS: usually originates from ".text", so the "code segment" (CPU) usually implies "text segments" (linker). BTW, I just noticed that these things are referred to as sections (not segments) in objdump’s documentation. Incnis Mrsi (talk) 21:10, 28 January 2013 (UTC)

I did move the "object file" segment discussion to that article. Peter Flass (talk) 15:01, 8 February 2014 (UTC)

x86 segmentation

Hint: On x86 CPUs within the "real mode" we becomes exactly 1088 KiB - 15 Bytes addressable space together with the combination of the segment and the offset part for to build an address. — Preceding unsigned comment added by 85.177.153.121 (talk) 08:42, 13 February 2014 (UTC)

A toxic mix of misunderstanding and misconception

The first line of the article defines the segmentation as "the division of a computer's primary memory into segments or sections", and then mixes the segmentation of physical memory and segmentation of virtual memory, although these are not the same thing, and thus should not be confused.

Continuing with the first paragraph:

In a computer system using segmentation, a reference to a memory location includes a value that identifies a segment and an offset within that segment. Segments or sections are also used in object files of compiled programs when they are linked together into a program image and when the image is loaded into memory.

This part is indeed talking about dividing "computer's primary memory into segments", and is actually referring to the segment:offset addressing scheme introduced with Intel's 8086 machines, which used 20-bit physical (linear) address obtained by shifting a 16-bit segment register 4 bit to left and adding a 16-bit offset register. It was a way to expand the addressable primary memory space (only to 20-bit though) without combining two registers linearly and obtaining a 32-bit address space.

Continuing with the second paragraph:

Segments usually correspond to natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer than paging alone.[1] Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may be shared between programs.[1]

This part is, like the rest of the article, talking about dividing the virtual address space of a process into logical segments, as the major advantage is that it allows flexible loading of a process by allowing the loading of different segments separately in both time and space domains, and also allows sharing of segments among processes.

What does \\//ikipedia say about this?

From the article "real mode":

Real mode, also called real address mode, is an operating mode of all x86-compatible CPUs. Real mode is characterized by a 20-bit segmented memory address space (giving exactly 1 MiB of addressable memory) and unlimited direct software access to all addressable memory, I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels.

From the article "segmentation fault" (that's a good article):

The term "segmentation" has various uses in computing; in the context of "segmentation fault", a term used since the 1950s, it refers to the address space of a program.[citation needed] With memory protection, only the program's own address space is readable, and of this, only the stack and the read-write portion of the data segment of a program are writable, while read-only data and the code segment are not writable. Thus attempting to read outside of the program's address space, or writing to a read-only segment of the address space, results in a segmentation fault, hence the name.

This should not be confused with memory segmentation (segmentation of the computer's address space, not an individual program's address space), which is a historical term for the approach to memory management nowadays known as paging.[2] The corresponding fault in this context is a "page fault", which has a different meaning. However, these are related in that an invalid page fault generally leads to a segmentation fault, and segmentation faults and page faults are both faults raised by the virtual memory management system. Segmentation faults can also occur independently of page faults: illegal access to a valid page is a segmentation fault, but not an invalid page fault, and segmentation faults can occur in the middle of a page (hence no page fault), for example in a buffer overflow that stays within a page but illegally overwrites memory.

The article should emphasize that the term "memory segmentation" applies to;

• segmentation of physical memory space of a computer (related to segment:offset addressing scheme used in real mode), which is considered at the hardware level (MMU), not the kernel level (where multi-process management is handled).
• segmentation of virtual memory space of running processes (related to and can be mixed with paging), which is considered at the kernel level, where each process has a virtual address space, and each process is given a "segment table" and a "page table" assuming both segmentation and paging are used by the kernel.

85.110.13.232 (talk) 19:44, 29 May 2015 (UTC)

OK.

~6000 characters: Article

~2700 characters ~1800 characters (for excerpts from other articles): Original comment in the talk page pointing out the need for improvement, and (of course) tipping off segmentation fault needs some too!

~7500 characters: First reply in the talk page

One doesn't need to be a statistician; one is or isn't.

If we have a system in which operands aren't directly referred to by addresses in physical memory, we can have all processes running in the same address space (that does not imply a lack of memory protection - you might, for example, have capability-based addressing) or we can have processes running in separate address spaces. That distinction is independent of how addresses are mapped to physical memory.

An operand might be mapped to a physical memory address in a number of ways:

• The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the physical address of the beginning of the segment, and the offset within that segment is added to that physical address to give the physical address of the operand. The segment descriptor might also have a "presence bit", with the reference faulting if the "presence bit" isn't set, and might also have a segment length, with the reference faulting if the offset within the segment goes past the end of the segment. There might also be permission bits in the segment, with the reference faulting if the permission (read, write, execute) isn't granted.

• The operand might be specified by an address. The upper bits of the address would be used to look in a page table (in memory or in registers) to find the physical address of the page containing the beginning of the operand, with the remaining bits added to the physical address of the page. The page table entries might have presence bits, with the reference faulting if any page table entry accessed has the presence bit not set, and permission bits, with the reference faulting if any page table entry accessed doesn't grant permission for the access. A page table entry might even have a length, with the reference faulting if the offset within the page going past the end of the page.

• The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the physical address of a page table for the segment, and the offset within that segment is used to look in that page table to find the physical address of the page in the segment containing the beginning of the operand, with the remaining bits added to the physical address of the page. The comments for both of the previous schemes apply here.

• The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the "logical" address of the beginning of the segment, and the offset within that segment added to that "logical" address to give the "logical" address of the operand. The comments about the first scheme given above apply here. The "logical" address is then used to look in a page table to find the physical address of the page containing the beginning of the operand. The comments about the second scheme given above apply here.

I've generally seen the first scheme referred to as "segmentation", the second scheme referred to as "paging", and the third scheme referred to as "segmentation plus paging". The fourth scheme is called IA-32 :-); the only CPUs I know of that implement it are IA-32 CPUs.

The first scheme is implemented on the B5000 and B5500, the Intel 80286, and the original HP 3000 series; there may be others. The third scheme is implemented on the GE 645 and its successors, and possibly other systems (I think a segment containing an array could be paged on later Burroughs mainframes). The second scheme is implemented on a lot of machines. The fourth scheme, as noted, is, as far as I know, unique to IA-32.

The way the segment descriptor, in the schemes that include segment descriptors, is found differs from machine to machine. An address might consist of a segment number combined with an offset-within segment, with the segment number used as an index into a table of segment descriptors; that's the most common scheme. (As I remember, in the original PDP-10, the 18-bit address space was split, so that the lower 128K words could be thought of as one segment and the upper 128K words thought of as another segment, with the "segment descriptors" being base-and-bounds registers.) In the Burroughs machines descriptors could sometimes be treated as in-memory objects by regular code; they were protected by tag bits. In the 80286, and in IA-32 processors, special instructions would load segment descriptors into segment registers, with most memory reference instructions specifying an offset within the segment; the segment register to be used is either implied by the type of reference or explicitly indicated by a prefix.

The schemes with segment descriptors are what has historically been referred to as "segmentation". See, for example, Chapter 16, "Segmentation", in Operating Systems: Three Easy Pieces, by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, and some of the older references in that chapter. That is what the first paragraph is referring to; it's not just talking about x86 real-mode segmentation.

(By the way, the book by the Arpaci-Duesseaus says, in a side note on page 4 of chapter 16, "The term segmentation fault or violation arises from a memory access on a segmented machine to an illegal address.. Humorously, the term persists, even on machines with no support for segmentation.")

All of this is "virtual" memory in the sense of "operands aren't directly referred to by their physical addresses". The "real mode" scheme on x86 is a relocation scheme, so it's only weakly a form of "virtual" memory; there are no segment descriptors - the segment number is, in effect, the physical address of the beginning of the segment, rather than being an index in a table of entries giving (among other things) the physical or logical addresses of the beginning of segments. There are no presence bits, so you can't take a "segment not present" or "page not present" fault.

The PDP-11, which is the system on which the UNIX system Lions was describing, implemented the second scheme; its address space wasn't segmented, in the sense of there being segment descriptors. It was, instead, divided into 8 4096-byte pages (that's the term DEC used in, for example, the PDP-11/45 Handbook). The page table was located in a bank of special registers. Each page had a pair of registers, one giving the physical address of the beginning of the page and one giving the length of the page (and, yes, references past the length of the page caused a fault), the protection of the page, and an indication of whether the length was the length from the beginning of the page or the end of the page.

So any notion of "segmentation" was provided by the OS, not the hardware. UNIX, on the PDP-11, didn't actually do any form of paging; a process could either be "swapped in", with the entire address space resident in memory.

So there's:

• "segmentation at the hardware level", which can - and, with the exception of x86 real mode, generally does - involve translating operand addresses to physical memory addresses, and is thus more than just segmentation of physical memory;
• "segmentation at the OS level", which might be implemented using "segmentation at the hardware level" or might not.

(BTW, thanks for tipping me off to the fact that segmentation fault needs some work.) Guy Harris (talk) 17:27, 30 May 2015 (UTC)

I may (or may not) have written this

Segments usually correspond to natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer than paging alone.[1] Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may be shared between programs.

i tend to try to forget about the x86 b@$tard version of segmentation, which is covered by another article anyhow. This was written with consideration of B5500 segmentation, where each ALGOL procedure or COBOL paragraph would be a segment. Data was also segmented somehow, although I'm not clear on how, perhaps each array or structure was a segment. Multics made each external PL/I proceure a segment (unless the linker was uesd, a later option). Data was usually grouped into the linkage segment, but there was a technique to create a segment containing all the data for a procedure (CDS). Peter Flass (talk) 21:14, 30 May 2015 (UTC)

You wrote

Segments usually represent natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer.

in this edit.

User:Vadmium added

Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may even be shared between programs.

in this edit; that text was later joined with your sentence when your sentence was moved. (You changed "represent" to "correspond to" in this edit.)

I'm not sure how the 5xxx, or B6xxx and successors, handled descriptors. From my quick attempts at reading the manuals, it's not as simple as "addresses have a segment ID and offset, and segment IDs are indices into a segment descriptor table"; I think descriptors can be handed around as data items, but are protected by tagging. I have the impression that arrays are segments, which can be paged in later versions of the system. My quick reading gave me the impression that stacks aren't explicitly represented by descriptors, but have a base and bounds, and are thus similar to segments.

Multics also, of course, let you map arbitrary named-in-the-file-system segments into the process's address space (that's the only way to access the file's data; that mapping is also how executables, linkage segments, data segments, etc. are mapped in).

x86 segmentation has three flavors:

• real mode "segmentation", which is mainly a trick to extend the physical address space and kinda sorta provide some relocation capabilities;
• 80286 protected mode segmentation, which is real segmentation, with segment registers containing segment descriptors rather than just the physical base address of the segment, and with the instructions to load and store segment registers using a segment ID, rather than the raw contents of the segmentation register, as the operand (load looks up the segment in the descriptor table, store stores the segment ID which is also stored in the segment register), and no paging is supported;
• IA-32 protected mode segmentation, which is real segmentation, but the segments don't have physical addresses, they have "linear" addresses, which existing within a 4GB paged "linear" address space (so segments don't have page tables, and a segment must either be mapped into the linear address space in its entirety or not mapped into the linear address space at all, even though not all of its pages are necessarily resident in physical memory). Guy Harris (talk) 22:50, 30 May 2015 (UTC)

Address space: The set of addressable physical or logical memory cells.

Physical address space: The set of addressable physical memory cells (e.g. for 4 GiB of installed primary memory on a byte addressed machine, physical address space comprises 2^32 elements).

Virtual address space: The set of addressable logical memory cells.

Multi-tasking: Multiple processes can be advancing concurrently (not necessarily in parallel), on the same physical address space, over a given period of time.

Address space of a process: The set of addresses that can be the value of a pointer in the source code of the process. In multi-tasking systems, the address space of a process is a virtual (or logical) address space, regardless of the relative sizes and the mapping between the process' address space and the physical address space, because concurrently running processes cannot occupy the same physical memory space, although they can share a part of it.

You write:

"If we have a system in which operands aren't directly referred to by addresses in physical memory, we can have all processes running in the same address space (...) or we can have processes running in separate address spaces".

Somebody else writes:

"If we have a system in which operands (or operators) are directly referred to by addresses in physical memory, we can still have all processes running in the same address space or we can have processes running in separate address spaces".

And, how do these two should look/sound/feel/compile together? When we are talking about memory, it is always virtual (or logical) vs. physical (or real); regardless of whether we are referring to data (operand) or instruction (operator), and regardless of whether data and instructions reside in the same physical memory (as in harvard vs. von Neumann), we are talking about memory addressing. I'd say trying to improve the article whose talk page we are populating right now (and which needs improvement) is at least an equally good alternative to trying to improve other articles (we're tipped off about).

The last edit to segmentation fault replaced an important part which emphasized that a segmentation fault is an access violation to logical segments of a compiler emitted file format. The edit was made with an edit summary stating "Remove completely wrong material, and try to state things more correctly. This could still use work. (Please look at the Multics system and at several other systems before jumping in". In fact, a bag of other newer operating systems than multics should be checked before jumping in. Anybody who has an interest on archaic operating systems, particularly multics, can check out The Multics Virtual Memory: Concepts and Design. It will remain in the pages (not segments) of the long lost past. The memory is still segmented, however modern operating systems (not talking about multics here) only use one segment and set all segment registers to the same value, and when a program receives a segmentation fault, it comes from the paging unit since the program referred to an invalid page, in its own virtual address space, as a program cannot refer to an address outside its own virtual address space, in which it is allowed to work by the operating system. As stated in Memory Translation and Segmentation, "the classic “Segmentation fault” Unix error message is not due to x86-style segments, but rather invalid memory addresses normally detected by the paging unit". The anatomy of a program in memory, that many programmers are used to, and which is composed of (logical) segments for kernel space, stack, mapped files, heap, bss, data, text, and un-allocated (free and thus non-addressable) memory are logical segments, not physical. From Tanenbaum's modern operating systems (3rd ed. p.234): "We emphasize that a segment is a logical entity, which the programmer is aware of and uses as a logical entity. A segment might contain a procedure, or an array, or a stack, or a collection of scalar variables, but usually it does not contain a mixture of different types". The last edit to segmentation fault removed the a piece in the article that was (I think) aimed to bridge the gap between logical segments of a PE/ELF/COFF/etc. executable file structure emitted by a language compiler (kernel space, stack, mapped files, heap, bss, data, text, un-allocated) and the concept of physical segments (i.e. contiguous segments in the physical primary memory) that can be used by an operating system to isolate processes by giving each process a separate segment.

Primary purpose of memory segmentation is protection, i.e. to prevent a process from jumping out of its own virtual address space into other processes' virtual address spaces. In real mode, there is no notion of memory protection or privilege, as there is no notion of multi-tasking, and thus it shouldn't be called virtual memory, in a weak form or in whatever form.

• When there isn't a multi-tasking kernel/OS running, the concept of "memory segmentation", if present, is merely an addressing scheme provided by a hardware/firmware such as MMU/BIOS, used to address physical memory segments, which you referred to as "segmentation at the hardware level".
• And, when there is a multi-tasking kernel/OS running, the concept of "memory segmentation", is present, and is a protection scheme provided by the kernel/OS, used to address virtual (logical) memory segments, which you referred to as "segmentation at the OS level".

By the way, I'd rather you referred to these in the article, not in your talk page post; explicitly stating these distinctions is, in my opinion, very much required to dispel "misunderstandings and misconceptions", hence the "original" post, up there somewhere.You're welcome for tipping you off to the fact that memory segmentation needs some work. And the rest is filling an article's talk page with twice as many (and probably more) characters as the article has, where the article does need improvements much more than the talk page indeed. Unfortunately, this is something quite common for EECS articles.

85.110.54.215 (talk) 14:40, 1 June 2015 (UTC)

Note that there are multi-tasking, protected, OSes single address space operating systems in which the address space of process A is the same address space as the address space of process B is the same address space as the address space of process C is the same address space as the address space of every other process on the system, so one should be careful when speaking of processes and address spaces.

My edit removed the claim that

This should not be confused with memory segmentation (segmentation of the computer's address space, not an individual program's address space), which is a historical term for the approach to memory management nowadays known as paging.

In Multics, the address space was segmented using segmentation hardware; paging was also used (the contents of a segment were paged), but it was most definitely not the case that the address space was divided into protected segments by breaking a single linear address space into regions, with holes between them, and treating all "page not present" faults in the holes as errors. It's irrelevant that Multics is now a historical OS; present-day OSes might not happen to use what segmentation hardware the processors on which they run, if any, to isolate regions of the address space, but Wikipedia's purpose is not to explain to computer users how Windows, various Unix-like OSes, and some other OSes such as z/OS work, it's to explain concepts. (And Multics wasn't unique there; for example, the Burroughs large systems and BiiN systems also had both segmentation and, in the later Burroughs systems and BiiN systems, paging.)

So segmentation at the hardware level - which, in most processors, provides protection - can be used to implement segmentation at the OS level. It can even be done so on systems that provide both segmentation and paging. Segmentation at the OS level can also be done on a system with only paging support in the MMU. That does not mean that "memory segmentation .. is a historical term for the approach to memory management nowadays known as paging".

Ignoring the fact that individual programs might not have separate address spaces, I assume that "segmentation of the computer's address space" really means "segmentation at the hardware level" and "segmentation of ... an individual program's address space" means "code is running in an address space with multiple regions possibly separated from each other" (although two of those sorts of segments could be contiguous, in which case an attempt to refer past the end of the first segment could, rather than being treated as an error and getting a fault, be interpreted as an attempt to refer to the beginning of the second segment; in many, if not all, systems with segmentation in hardware, segment offset addresses were usually used or constructed in fashions such that if you went past the end of one segment that wasn't interpreted as referring to the beginning of another segment - the best you can do with only paging hardware is to put space between the segments and treat page faults in that space as errors).

So "segmentation of the computer's address space", i.e. "segmentation at the hardware level", is segmentation, not paging, and is, therefore, most definitely not "nowadays known as paging". (Given that some systems did both segmentation and paging, it couldn't possibly be "known as paging".) "Segmentation of ... an individual program's address space" could be done either with segmentation at the hardware level, if the hardware supports it, or paging.

As for where the "segmentation fault" term came from, well, as I said earlier, Chapter 16, "Segmentation" of the Arpaci-Dusseaus' "Operating Systems: Three Easy Pieces" says the term comes from segmented machines (i.e., machines that do segmentation at the hardware level), but persists on systems that don't do segmentation at the hardware level.

So the segmentation fault article must not make the false claim that "memory segmentation .. is a historical term for the approach to memory management nowadays known as paging". It should, perhaps, note that segmentation at the OS level might be implemented with paging, and is so implemented in current operating systems, but that's it.

"Primary purpose of memory segmentation is protection, i.e. to prevent a process from jumping out of its own virtual address space into other processes' virtual address spaces. " Yes, the primary purpose of segmentation is protection; however, not all OSes put processes in individual virtual address spaces - you might have a single address space operating system and use capabilities for protection (and, no, capability hardware is not just an old dead historical idea), and it's also used to prevent a process from jumping outside the bounds of its own objects.

"When there isn't a multi-tasking kernel/OS running, the concept of "memory segmentation", if present, is merely an addressing scheme provided by a hardware/firmware such as MMU/BIOS, used to address physical memory segments, which you referred to as "segmentation at the hardware level"." No, "segmentation at the hardware level" is whatever form of segmentation is done by hardware. That segmentation performs, at minimum, relocation; it might also perform bounds checking, as is the case on the 80286, IA-32 processors, the GE 645 and its successors, the Burroughs B5000 and successors, the BiiN processors, etc.. (And multi-tasking OSes, such as 8086/8088 versions of UNIX, existed that didn't provide address spaces protected from each other.)

"And, when there is a multi-tasking kernel/OS running, the concept of "memory segmentation", is present, and is a protection scheme provided by the kernel/OS, used to address virtual (logical) memory segments, which you referred to as "segmentation at the OS level"." (We'll leave aside here the fact that a multi-tasking OS might not even provide memory protection, as noted in the previous paragraph.) Such an OS could:

• run all processes in a single address space, and rely on mechanisms other than separate address spaces to provide protection - possibly, for example, providing an address space consisting of multiple segments, with a process being unable to construct descriptors for segments (except in the kernel), and only being able to address segments to which it already has a descriptor (meaning those descriptors are capabilities);
• run all processes in their own address spaces, with the address space starting at a given virtual address and ending at another given virtual address space, so that there's only one "segment" within the address space (think of the PDP-6 Monitor, i.e. the pre-PDP-10 version of TOPS-10);
• run all processes in their own address spaces, with the address space divided into multiple segments - that could be done with segmentation hardware, i.e. "segmentation at the hardware level", or with paging and laying out the address space in multiple regions.

As for long discussions in talk pages, if you don't have fundamental disagreements, maybe you can have short pages. However, you started out with ~4600 characters, much of which I found seemed to misunderstand some of the concepts here or to have some recentism (as in "thinking of x86 segmentation rather than segmentation as used on other systems"), and I needed to dispel some of the misunderstandings. So we do have some fundamental disagreements (including, perhaps, disagreement whether Wikipedia should tell people how systems work now or educate them about all the ways a system could work and the ways they did work in the past - and could possibly work in the future; I'm extremely firmly in the latter camp), and there's going to have to be a fair bit of discussion (unless you're willing to just let me edit this article and segmentation fault as I deem fit). Guy Harris (talk) 18:37, 1 June 2015 (UTC)

BTW, Gustavo Duarte's "Memory Translation and Segmentation" essay should probably be called "x86 Memory Translation and Segmentation"; as he states in the first paragraph, "This post is the first in a series about memory and protection in Intel-compatible (x86) computers", so it doesn't discuss memory translation and segmentation in general, it just discusses how x86 processors happen to implement them. Don't use it to discuss the notion of a segmentation fault in general; those faults can be generated by the segmentation part of the memory management unit - that's what happened on System V/286, for example (obviously, System V/286 didn't do paging, as the 80286 didn't do paging).

Wow! long discussion. It's useful, but getting hard to follow. I'll only add a few comments.

• I agree that 286 and 386 protected mode provides "real" segmentation; 8086/88 doesn't and shouldn't be covered in a lot of detail here, although it's worth mentioning.
• "segmentation of ... an individual program's address space" might be exemplified by MVS, where a program's address space can contain multiple "memory subpools" with different protection and access rights.
• "Primary purpose of memory segmentation is protection," I'm not sure it's the primary purpose, but it's certainly an important purpose.
• "disagreement whether Wikipedia should tell people how systems work now or educate them about all the ways a system could work and the ways they did work in the past - and could possibly work in the future; I'm extremely firmly in the latter camp)" Agreed.
• Can someone summarize suggested changes to the article in a couple of paragraphs?

Peter Flass (talk) 19:38, 1 June 2015 (UTC)

About all I'd do is somehow distinguish "dividing an address space into regions" from "segmentation in the MMU", clearly indicating that the former can be implemented using the latter but doesn't have to be implemented using the latter. I have the introduction more clearly indicate that this page refers not to just "dividing an address space into regions" but to doing so by doing more than just having more than one contiguous region, i.e. treating segments as first-class objects in the hardware. I think the "x86 architecture" section adequately deals with x86's peculiarities and the limitations of real-mode segmentation. Perhaps the general notion of "dividing an address space into regions" deserves a separate page, but I'm not inclined to think so. Guy Harris (talk) 20:58, 1 June 2015 (UTC)

I think the bare-minimum requirement of a public encyclopedia entry on "memory segmentation" can be stated, in plain thinking, as follows: A lot of people are programming and getting memory segmentation errors along the way, and many of them haven't been playing with computers since 70s. Understanding of the memory layout of a running program is crucial. Therefore, the article should emphasize the relationship between segments in an executable/linkable file format (as emitted by a compiler) and the segments of the physical memory on which that file is loaded and running (as managed by the operating system and hardware), i.e. "which segments are we talking about, and when?", and make sure a reader would have answers regarding modern systems, on which s/he is getting segmentation faults, before history. Otherwise, I put stock in facts anyway, not camps. 85.110.59.236 (talk) 22:20, 1 June 2015 (UTC)

What you want is not an encyclopedia article, it's a lesson in a programming class. Feel free to write, on your own Web site, a programming tutorial that explains to the horde of people writing code and getting segmentation errors, but don't try to turn this article into into "Avoiding Illegal Memory References For Dummies". Wikipedia is not a howto. (If a lot of people are programming and getting memory segmentation errors along the way, we need better programming environments that make it easier to write correct code and harder to write incorrect code.) It's not the job of "Depression (economics)" to tell people what not to do in a modern economy to avoid it going into a depression or to get it out of a depression, and it's not the job of "Memory segmentation" - or "Segmentation fault" - to tell people how to avoid segmentation faults or fix their code when it gets one.

So, yes, we have a fundamental disagreement, and the chances that you'll convince me that your point of view is correct are so close to zero as to be well approximated by zero. Guy Harris (talk) 23:41, 1 June 2015 (UTC)

Wanting to convince somebody who is admittedly inconvincible and yet still choses to argue requires a significant faith in that person's dishonesty and/or a powerful desire to waste time: I have no intention what so ever to waste anybody's time (including mine), and I sure do hope that you're not that dishonest about your state of mind (although, as I said, I put stock in facts, not camps). So, I neither want nor need to convince you, and frankly I think nobody should want or need it when somebody admits there is zero chance that s/he'll be convinced. Luckily, in a project edited by the "public", it doesn't matter much if a single person is convinced by a suggestion or not. If you find yourself not convinced by a suggestion in a talk page and explicitly stating that there is zero chance that you'll be convinced, feel free to step aside and let others have their opinions on the suggestion too, as you already have yours, although I wouldn't venture to comment on how healthy an opinion whose chance to be changed is zero is; I can just hope that's a lousy approximation than the truth.

However, I have to say that wild speculations in the above paragraph kind of made me question the intentions within the discussion:

(1) Nobody suggested writing such a thing as tutorial/howto, not implicitly and not explicitly. You need to relax about blaming others. Such a strange speculation to come up with though. The above paragraph just emphasized that segmentation fault is quite common in software development cycle, and therefore the relationship between logical memory segments (within COFF, or ELF, or PE, or the old a.out formats) and physical memory segments (within physical memory) is worth noting. Although I have to add, taking any discussion onto fuzzy borders of politics is waste of everybody's time, e.g. "oh my god, look at dd (unix), somebody is writing a howto on backup and restore of MBR, hold it! wikipedia is not a howto". These kind of actions prohibit improvements to wikipedia. dd (unix), and many^many other wikipedia articles, are doing quite alright with their sub-sections providing examples, as long as they are not interpreted as howtos. A simple paragraph or two that aims to bridge the gap between logical memory segments and physical memory segments could hardly look like a "howto example" anyway.

(2) The simple suggestion that was made above is, in exact words (unfortunately only ~3800 characters apart), memory segmentation should emphasize the relationship between segments in an executable/linkable file format (as emitted by a compiler) and the segments of the physical memory on which that file is loaded and running (as managed by the operating system and hardware). And, unfortunately, the wild speculations are that this would transform the article from an encyclopedia article into a programming lesson ("lesson in a programming class"), or a howto, or probably some book titled "Avoiding Illegal Memory References For Dummies".

So, why memory segmentation should at least explain, briefly (now that we know the discussion is open to speculations), the relationship between logical memory segments and physical memory segments? Well because there are logical memory segments and physical memory segments, and their relationship goes a little beyond name resemblance, that's why. As stated in Code segment: "In computing, a code segment, also known as a text segment or simply as text, is a portion of an object file or the corresponding section of the program's virtual address space that contains executable instructions". Since they are both "memory segments", memory segmentation would do better if it at least provided a brief explanation (not a book-long, or howto style, or any other speculative style, but a wikipedia style explanation; we do explain things here too, don't we?), without neglecting more commonly used systems, how logical memory segments correspond to physical memory segments: The whole suggestion, and this discussion (not to be judged by the historical content), is about this simple phrase, in exact words or as interpreted (without deriving speculations from the suggestion phrase).

85.110.74.250 (talk) 18:21, 2 June 2015 (UTC)

I've pointed you to factual information about segmentation in various computers, current and historical, and you've either disregarded it or chose to treat it as unimportant as it's not relevant to present-day programmers getting segmentation violations. This article should be about the general concept of segmentation, not about its manifestation in present-day operating systems, in order to be encyclopedic. I have not seen any indication that you would ever be convinced of that, so further discussion here seems pointless. Guy Harris (talk) 19:23, 2 June 2015 (UTC)

This article reads as if segmentation is a feature. Obviously it was written in retrospective with an intel x86 OS programmer mindset.
S. is not a feature or option but a severe limitation. Paging and virtual memory are something entirely unrelated. S. is the consequence from the disparity between how many bits it takes to represent a western alphabet character (5-8) and how many bit it takes to address a memory worth using (min 20-24).
When transistors (and memory) are expensive one can simply not afford to work with 32 bit addresses. Until the 90's the price/cost of a PC did not allow for a full 24 or 32 bit architecture.
"Primary purpose of memory segmentation is protection"; is complete nonsense. That is a byproduct of a specific and smart implementation.
--Moritzgedig (talk) 09:12, 30 December 2019 (UTC)

On the contrary:

• This article makes a distinction between the segmentation found in some non-x86 systems with the segmentation in 16-bit and 32-bit mode on x86 processors, so it's hardly "written in retrospective with an intel x86 OS programmer mindset".
• It's a limitation, on non-x86 systems, in that segment sizes are limited - for example, the maximum segment size on the GE 645 and Honeywell 6180 was 2¹⁸ 36-bit words, or 2²⁰ 9-bit bytes, so Multics had to have the notion of "multi-segment files".
• It has nothing whatsoever to do with the disparity between the size of a character and the size of memory - where does that notion come from?
• Segmentation existed long before personal computers, so "Until the 90's the price/cost of a PC did not allow for a full 24 or 32 bit architecture." is irrelevant.

And protection is a significant purpose of segmentation, even if it isn't the primary purpose, in the non-x86 systems discussed. Guy Harris (talk) 20:07, 30 December 2019 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Memory segmentation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20111013222125/http://www.bitsavers.org/pdf/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf to http://www.bitsavers.org/pdf/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:47, 25 January 2018 (UTC)

It moved (bitsavers.org moved manuals about chips into a separate "components" collection). Guy Harris (talk) 18:50, 25 January 2018 (UTC)

Incomplete history in the lead

The lead currently states Segmentation was originally invented as a method by which system software could isolate software processes (tasks) and data they are using. It was intended to increase reliability of the systems running multiple processes simultaneously. However, on the B5000, the Master Control Program (MCP) also used segmentation to manage memory; a process could run even when some of its segments were swapped out.

Given that there is a History section, I'm not sure that this even belongs in the lead. I'm not sure whether to remove the paragraph, delete it, or merge it into History. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:27, 7 August 2022 (UTC)

Short description?

@Widefox: Edit https://en.wikipedia.org/w/index.php?title=Memory_segmentation&curid=1323131&diff=1126677852&oldid=1112702082 by Widefox added the short description The division of computer's primary memory into segments or sections. That description is too general, since it applies to architectures where the OS is not free to move segments. How about {{Short description|The division of computer's primary memory into separately relocatable segments or sections}}? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:23, 11 December 2022 (UTC)

Feel free to change it to what you like. Per WP:SDCONTENT ...short descriptions are not intended to define the subject of the article, but rather to distinguish it from other similarly named articles in search results... . Widefox; talk 15:51, 11 December 2022 (UTC)

India Education Program course assignment

This article was the subject of an educational assignment at Department of Electronics and Telecommunication, College of Engineering, Pune, India supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:59, 1 February 2023 (UTC)

Examples?

#Examples currently has #S/370 architecture and #x86 architecture; I believe that Burroughs MCP on the B5000 and B6500 would be better examples. All virtual operating systems on the IBM System/370 rely on paging and make minimal use of segmentation. Similarly, while some systems exploited segmentation on the Intel 80286, I'm not aware of any that exploited it on subsequent chips.

I'm not sure whether it would be better to replace the current examples or simply add new ones. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:24, 3 January 2024 (UTC)

The GE 645/Honeywell 6180 Multics might also be a good example as well; it's a more "typical" implementation of segmentation than the Burroughs machines are, so both would be interesting. Guy Harris (talk) 06:39, 24 January 2024 (UTC)

Burroughs large system architectures is two distinct lines

@Ian.joyner: Edit permalink/1251427698 reverted the text Burroughs used segmentation on two different product lines.

The oldest of these, the B5000, was followed by the B5500 and B5700, the last of the line.

The newer line was inspired by the B5000, but has a radically different architecture. It started with the B6500 and continued with various B6x00 and B7x00 models, as well as the B5900. An enhanced version of the architecture is still commercially available from Unisys.

with the comment Undid revision It is not true that B6000 was a separate or radically different product line from B5000. The architecture was the same but with some enhancements. The implementation technology might have been very different. Chatul might be thinking of the B1000 or B2/3/4000 product lines. Please provide reasoning behind the comments.

A cursory inspection of the references in various wikipedia articles, e.g., Burroughs Large Systems, Burroughs large systems descriptors, B5000 instruction set, Burroughs B6x00-7x00 instruction set, makes it clear that the two architecture are *not* the same, or even close to each other. Burroughs Large Systems § B6500, B6700/B7700, and successors lists some of the differences:

• The B6500 had variable length instructions with an 8-bit syllable instead of fixed length instructions with a 12-bit syllable.
• The B6500 had a 51-bit instead of a 48-bit word, and used 3 bits as a tag
• The B6500 had Symmetric Multiprocessing (SMP)
• The B6500 had a Saguaro stack
• The B6500 had paged arrays
• The B6500 had Display Registers, D1 thru D32 to allow nested subroutines to access variables in outer blocks.

As well, the formats of descriptors and other control words were different, and the B6500 line used address couples instead of the encoded ten-bit fields used in the B5000 line. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:12, 16 October 2024 (UTC)

These are small differences that were enhancements to the B5000 line. The B6000 line was still a continuation of that line and not radically different. That gives the wrong idea altogether. Ian.joyner (talk) 00:13, 30 November 2024 (UTC)

These are small differences What is your criterion for "small" vs. "not-small"?

The B6000 line was still a continuation of that line ...that requires you to recompile your code to allow it to run on the continuation, unlike, for example, S/360 vs. S/370 vs S/370/XA vs. ESA/370 vs. ESA/390 vs. z/Architecture.

and not radically different. The key concept of the B5000 line, access to operands through descriptors, is also used in the B6000 line, as is the notion of using an evaluation stack for arithmetic. However, it's not as if you could roll out a B5000-series machine and plug in a B6000-series machine with just a tape dump and restore; that might work for data files if those don't contain tagged data (i.e., if they're made up of 48-it words), but it wouldn't work for executable code files.

That might not have made a difference at the time the B6000 line was introduced, as that might have been a time when most software was either supplied by the vendor, who could supply compatible versions of software for the new machines, or customer-written, as that would all have been written in high-level languages and could presumably just be recompiled (unlike S/360 software, much of which was written in assembler language and would have to be rewritten of a new IBM computer, with a new instruction set but a compatible operating system, replaced an S/360).

But by the time third-party commercial software was common, it would've been harder for Burroughs to replace the B6000 series with machines that had an incompatible instruction set.

And given that readers are likely to think of a line of machines that can't run application software for their predecessor line without recompiling or getting a recompiled version from the vendor as not being a continuation of the predecessor, showing the B5000 and B6000 series as a single series would also give the wrong idea. Guy Harris (talk) 02:03, 30 November 2024 (UTC)

Sorry Guy, what you just wrote is nonsense. You reasoning is completely incorrect.

"showing the B5000 and B6000 series as a single series would also give the wrong idea"

Not the wrong idea at all. The B6000 series was a continuation of the B5000. In fact, that continued in the B5900.

Clearly, Burroughs intended that the B5000 machines be upgraded to the later systems.

They were NOT a radically different architecture as the part that I removed claimed.

My correction was correct. Ian.joyner (talk) 03:52, 30 November 2024 (UTC)

Calling it nonsense doesn't change the facts. Just because Burroughs expect users to migrate (*not* upgrade) from B5xx to B6xx doesn't mean that the architectures were remotely similar, any more than the IBM 650 was similar to the 7070. The differences that I mentioned are major, not minor. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:34, 2 December 2024 (UTC)

Except it was not migration, it was upgrading.

The B6000 WAS a continuation of the B5000 architecture. You are basing your whole reasoning here on your lack of understanding.

B5000/B6000/B7000 all models, then A Series, then Clearpath MCP systems are all part of this same architecture. Ian.joyner (talk) 03:46, 3 December 2024 (UTC)

Notes

References