CS 134

Segmentation

  • Dog speaking

    You said our scheme was wasteful. How…?

Running Low on Space

In the diagram below, three users are busy editing with neovim. Perhaps another user might like to start a process to run emacs, but they can't because the machine is almost out of memory.

The code for neovim is shown in a darker turquoise color, while the data used by the process is in our usual green.

OS (256 KB) Process 1 neovim Process 2 neovim Process 3 neovim
Everybody Loves neovim
  • Horse speaking

    Hay! I bet all the neovim code is the same! Why do we have to have three copies of it?

  • PinkRobot speaking

    Right now, we don't have any way not to. But perhaps if we went back to our friendly CPU designer, we could ask for a bit of help.

  • Hedgehog speaking

    A way to share. I like it!

  • Pig speaking

    I have an idea. On the CPU, we actually want MORE of something!

We've already asked our CPU designer to provide us with base and limit registers, and then used that to provide logical addressing to our programs. What would we ask for to allow us to share code between processes?

  • Cat speaking

    I think I see it. We could have separate logical spaces for code and data, and then we could share the code between processes. We'd need a base and limit register for each space, but that doesn't seem like a lot to ask for.

  • Horse speaking

    Hay! Can the CPU even tell when its accessing code or data?

  • PinkRobot speaking

    Yes. The CPU knows when it's doing an instruction fetch to read code, and when it's doing a data read or write.

We'll call these logical spaces segments. We'll have a segment for code and another segment for data. Each segment will have its own base and limit registers. By making the code segment read-only, we can share the code between processes, as shown in the following diagram.

Process 2 Process 3 OS (256 KB) Process 1 neovim
Less neovim is More
  • Duck speaking

    We can go even further, let's have a segment for the stack, too!

  • PinkRobot speaking

    That's actually a good idea. It will make it easier to move or grow the stack, and avoid unused space in the data segment just in case the stack grows.

  • Rabbit speaking

    In fact, the Intel X86 has segment registers CS, DS, SS, and ES for code, data, stack, and extra data. These registers have existed since the debut of the 8086 in 1978, although the CPU didn't use them for memory protection until the 80286 in 1982. In 1985, the 80386 added the FS and GS registers for extra segments. Processor instructions could specify which segment to use, as in mov ax, [es:0x1234], to use the extra segment register ES to access memory instead of the default, DS.

  • Goat speaking

    Meh. The 1980s are alive in Claremont. Can we go home now?

  • PinkRobot speaking

    Actually, we've reached a pretty good point to stop. We'll come back to segments and generalize them a bit next time.

  • Rabbit speaking

    Also, today's x86 CPUs still have segment registers, so they still have some relevance today. That said, they're not used by the OS to provide processes with shared-but-protected memory areas; instead they tend to be used inside processes for things like thread-local storage, allowing “the same location” to be different for different threads. But CPUs such as ARM and RISC-V don't have segment registers, and have to find a different way to provide the same functionality.

(When logged in, completion status appears here.)