CP/M and VAX/VMS Memory Layout

Bruce Ediger

It’s often said that DEC operating systems influenced the design of the CP/M microcomputer OS. Let’s examine that assertion by looking at how a process was laid out in memory.

Here’s CP/M’s memory map:

CP/M memory map

Here’s VAX/VMS memory map for a single process:

VAX/VMS single process memory map

The VMS single process memory layout image is from a widely circulated paper, Virtual Memory Management in the VAX/VMS Operating System by Henry M. Levy and Peter H. Lipman, Digital Equipment Corporation.

I’ve never been a fan of VMS, and even this small excursion into VMS internals has reminded me of several reasons.

  1. DEC had the terrible habit of putting low memory addresses at the top of any graphic, and high addresses at the bottom, in contravention of all common sense.
  2. VMS wasn’t all that well documented. VMS fans raved about the “orange wall” of books, but the VMS sysadmin culture was such that mere users didn’t deserve to get their grubby paws on it. This Levy & Lipman paper has been cited and bandied about for years, but it’s just a paper. VAX/VMS had a really long lifespan, from about 1977 to at least the early 1990s, maybe 25 years. That’s a long time for a single paper to represent all the documentation about a process address space.

In any case, if you can mentally invert the “P0” VAX/VMS address space diagram, you can see a good deal of similarity between “P0” and the CP/M memory layout. You can also see why VMS processes were so heavy: there was a lot of structure to them. Each process had an entire shell (“command language” in the diagram) in it. “Running a program” had a different meaning in VAX/VMS than it does in Unix-like OSes.

I haven’t been able to dig up any memory layouts for other DEC operating systems, like RSTS, TOPS-10, RSX-11 or TENEX/TOPS-20. In fact, it looks like an RSX-11 “task” was just linked in as part of a single program running on a PDP-11. I did find some hints in a TENEX manual that TENEX processes were more Unix-like than CP/M or VMS like. See all the talk about “forks”, which appear to be what I would call “child processes”.