Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
Does anyone know of any operating system that used static memory partitioning: contiguous physical memory allocation with one process per partition, one partition per process, partitions generated at build time, and existing independently of being used/not used?
I am particularly interested in systems that required that all partitions were of the same [fixed] size. Were there any such systems?
The RSX-11 {D/M/M-PLUS/S} family of operating systems, running on PDP-11 minicomputers, divided real memory into partitions. Partitions were mostly set up at system generation time; you could define partitions in a running system, but that was less common.
The RSX-11 family were a reimplementation, on the 16-bit PDP-11, of RSX-15 on the 18-bit PDP-15, so many of the ideas were carried over from there. This includes partitioning of memory.
To quote from the RSX-15 exec manual,
Partitions and SYSTEM COMMON Blocks are fixed at system configuration time and cannot be altered at run time. Tasks are built to execute in specific partitions, and, any number of Tasks may be built to execute in the same. partition.
This to me is the essential feature of partitioning - they are relatively static memory allocations, certainly not created 'on demand' as programs start executing.
I'm much more familiar with the PDP-11 systems, but the principle is the same. One important fact is that smaller 11's may not have memory management hardware (and thus had no more than 28K words memory).
This means that tasks (a term used for both the program-on-disk and program-in-executions) needed to be built for the address they'd be loaded at. That meant in turn that in practical terms you'd need to define a set of useful base addresses, which is to say, to partition memory. You'd create one partition for every task you wanted to be running and in memory simultaneously. You then had to decide at task-build time ("link time" in other operating systems) which partition a task would execute in, and the task builder would base the task for that address.
Example: you'd create partitions A, B, C, and D - this would allow 4 tasks to be in memory at the same time; the exact mix that was possible depended on which tasks were built for each partition: A, B, C or D.
The system could checkpoint (swap out) a task to permit a higher-priority task to be loaded into a particular partition. However, one task at most was 'in' a partition at any point in time. (And the partition still existed when no tasks were in it).
Mapped RSX-11M (i.e., running on a PDP-11 with memory management hardware and thus capable of having more memory) also allowed fixed memory partitioning, and required it to some degree, though since tasks started at virtual 0, there was no need to build a task for a particular partition.
But it was still good practice to dedicate partitions for certain uses, as (for example) you could avoid the memory fragmentation that would result if you loaded device drivers into the same partition used for user tasks -- the driver would be immovable once loaded.
It was also somewhat common to dedicate partitions for high-priority tasks, for example the file system ACP (handled file actions except for the actual read-write calls) might get its own partition to avoid fighting for memory with user tasks.
It was however not a necessity to partition memory in a fine-grained manner in such a system. Typically, "most" of memory was allocated to a general partition, which could, as a partition-definition option, be dynamically sliced up into subpartitions (one per task) to meet the need for whatever was currently executing -- i.e., it worked like you expect non-paged systems to work, each task got a contiguous piece of memory that matched its size requirements.
So: partitions had a fixed size, but partitions could optionally be allowed to be split into dynamically-allocated subpartitions.
Here's part of the partition layout from a running RSX-11M-Plus system (a large-PDP-11 system, but it's all I have handy). Partitions and subpartitions appear in real-memory order.
>PAR
SECPOL 117734 00200400 00200000 SEC POOL
SYSPAR 117670 00400400 00205400 MAIN
117624 00400400 00115300 RO COM !DIR11M!
117434 00515700 00005200 TASK <...LDR>
117230 00523100 00033300 TASK <MCR...>
117024 00556400 00010500 TASK [TKTN ]
116620 00567100 00003200 TASK [SHF...]
116414 00572300 00013500 TASK [RCT...]
DRVPAR 116334 00606000 00173000 MAIN
116270 00606000 00006600 RO COM !TTEXT !
116204 00614600 00020600 RO COM !TTCOM !
116120 00635400 00034200 DRIVER (TT:)
115450 00671600 00001300 DRIVER (DK:)
...
110560 00777300 00001500 DRIVER (RD:)
GEN 110514 01001000 15777000 MAIN
110450 01001000 00002000 RO COM !DYCOM !
025544 01003000 00007500 TASK <PMT...>
...
All of the partitions (SECPOL, SYSPAR, DRVPAR, GEN) are fixed-size paritions. SECPOL is a memory pool for the OS; SYSPAR is for system-critical tasks and the directives (syscalls); DRVPAR is for drivers; and GEN is for everything else. The partition sizes are determined - with user input - at system generation time.
The numerical columns are (as far as I recall) address of the partition control block, base of partition, length of partition. All in octal, since we only have 8 fingers.
Each of those partitions is dynamically divided into subpartitions by the OS as objects (drivers, tasks, etc.) are loaded into the partitions.
The PDP-8 is a 12-bit computer. As such it has a word and pointer size of 12-bits — meaning it can access 4k words using a single word pointer.
Later models added bank switching (KM8E) and 3 extra address lines so that up to 32k words (8x4k) words could be populated, now having 15 address lines. (Core memory boards, 4k words each, you could see each bit!)
The TSS/8 operating system gave each program/process one of the 4k banks, regardless of program size (i.e. whether smaller or larger than 4k). The OS did not allow user programs to use bank switching, so they ran as if there was only 4k in the machine — though they did have the benefit of system calls whose implementation did not take space in the user's 4k.
The operating system occupied two 4k banks, and the others were available for running processes. The operating system could suspend a process to disc, so a system with 16k, for example, could have (the operating system, plus) two memory-resident user processes and some number more suspended on disc.
If a program didn't need the full 4k there was no way to release that back to another program.
Programs that needed more storage could use disc, rather manually. When the program was running file handle #0 referred to the program itself (much like stdin/stdout in unix), so that additional code and/or data could be fairly easily read or written using a system call.
You got 4k, full stop — there was no allocating (or releasing) additional memory. The 4k you got was a complete bank (so in terms of 15-bit addresses the lower 12-bits of the bank's address were 0's, i.e. 4k aligned) — the banks were effectively partitioned in advance.
During the heyday of the Intel 80386, there were many operating systems that relied on that CPU's virtual 8086 mode to multitask programs that were written for x86 real-mode.
By allowing real-mode programs to transparently use the segmented, 20-bit address space that they expected, these Operating Systems provided a fixed-size memory partition to each real-mode application. This partitioning was done under the control of the monitor running in protected mode, so the memory pages were fully protected from other applications while appearing to each application as if it had access to its full 20-bit memory space. So, it was a full virtual machine partitioning, but the partitions appeared as a fixed memory size to the multitasking applications.
The Acorn MOS, as deployed in the BBC Micro, offers built-in support for paged ROMs. Paged ROMs have a fixed 16kb window in the address space, and amongst other things may contain filing systems, languages or other programs.
A BBC or Electron fitted with more than one paged ROM will therefore have a fixed 16kb ROM window in which the current application sits, and the user may opt to exit that program and switch to another. Or, if one of the other ROMs is a filing system or the interpreted language that an application is written in, the MOS will do it automatically as required.
The following has been ruled an impermissible example since a program may simultaneously occupy more than one segment, but is preserved for posterity:
Classic Mac OS applications are divided into 16kb segments and a jump table. Code within a segment uses PC-relative addressing and jumps; to get to code in another segment it uses the jump table, which is dynamically reprogrammed to redirect into the segment loader as and when segments are unloaded. So it's a lot like a virtual memory subsystem except that there's no automatic address translation, and no automatic page faults. Developers just have to follow the rules.
As a result, Classic Mac OS uses fixed-size memory partitioning for application code.
The definition to which you linked is very specific, and you put a further constraint on it that the partitions must all be the same size (the definition to which you linked makes it clear they need not be; the example they give uses four "blocks," which I assume they feel is another word for "partition," of three different sizes).
The CDC 6600 is definitely not fixed by your definition, and technically not even by the source definition, since the sizes of partitions could vary as processes came and went (e.g., one large area used by one process could be used by two smaller processes later), and fragmentation could be avoided by stopping a process, copying it to a different range of locations in physical memory, and continuing the process. It probably is thus "variable partitioning" (mentioned but not really defined in the source), since processes are "contiguous" in both the actual meaning of the word and by their definition of that as "loaded entirely in main memory."
I wouldn't, however, rely on your source as any sort of indication that what they described ever even existed, much less as a good taxonomy of actual systems; the source seems to be both overly vague and lacking in any sort of references.
I leave the detailed description of the CDC 6600 here in case it's useful in developing better taxonomies and/or questions.
The CDC 6600 had a memory remapping and protection system where each process got a contiguious area of memory starting at virtual address 0 and of arbitrary size less than or equal to main memory. Multiple processes were thus possible, but each always started at virtual address 0 and the physical memory allocated was a singal contiguous block. From Wikipedia:
User programs are restricted to use only a contiguous area of main memory. The portion of memory to which an executing program has access is controlled by the RA (Relative Address) and FL (Field Length) registers which are not accessible to the user program. When a user program tries to read or write a word in central memory at address a, the processor will first verify that a is between 0 and FL-1. If it is, the processor accesses the word in central memory at address RA+a. This process is known as base-bound relocation; each user program sees core memory as a contiguous block words with length FL, starting with address 0; in fact the program may be anywhere in the physical memory. Using this technique, each user program can be moved ("relocated") in main memory by the operating system, as long as the RA register reflects its position in memory. A user program which attempts to access memory outside the allowed range (that is, with an address which is not less than FL) will trigger an interrupt, and will be terminated by the operating system. When this happens, the operating system may create a core dump which records the contents of the program's memory and registers in a file, allowing the developer of the program a means to know what happened. Note the distinction with virtual memory systems; in this case, the entirety of a process's addressable space must be in core memory, must be contiguous, and its size cannot be larger than the real memory capacity.
I used an operating system with a MODCOMP minicomputer c. 1978 that had fixed partitioning. I believe it was the MAX III operating system and a MODCOMP II computer. During system build, you created partitions for foreground and real-time processes. The foreground partitions you could use for program development; the background partitions were for the real-time programs. They were fixed size (but not necessarily the same size).
I think that which program ran in the background partition or partitions was set during build time. To change program you had to rebuild.
Here's another off the road candidate: DoubleDuty for the TRS-80 Model 4
It split the 128 KiB main RAM of a full fitted Model 4 into two 64 KiB partitions, each able to run a stand alone application, plus a 16 KiB partition with just DOS.
(Catalogue scan taken from the Radio Shack Catalog Archive)
