13 Nov
2003
13 Nov
'03
11:58 p.m.
Hans and Eric write about memory management.
Hans now comments:
I tend to agree. The PDP-11 MMU was
external to the CPU, was
transparent from a user point of view, and *still* limited the
user [process] to an adressable 64K (+64K if SepID). Unless a
process repeatedly calls the monitor (kernel) for remapping of
its address space, the visible area will always remain that.
What, the 64K
segments that alias on paragraph boundaries?
Yecch! What a kludge! The PDP-11 had better memory management
for a 64KB address space at least seven years earlier.
Excuse me? The PDP-11 is a classic example for an external
MMU, completely invisible to a user task. Nice if you just
want to run old Software that expects a 28K addres space.
But without expesive OS calls, and the MMUs equivalent of
bank switching, it just allows to access said 28K (well,
32K since the IO may have been not mapped in). Try to see the segment address as a handle given to a
user
task as result of a mempry request to access the requested
memory. As a user task, I don't care where the memory is
located, I don't need the information - nor does any other
part of the operation system, except for memory management.
Now, still beeing a strict 16 Bit CPU, this little trick
allows a 16 Bit user process to access up to 65K of 65K
segments. How many memory realy was available and how it
was organized did not concern to a user programm. While
still beeing on a real mode CPU, the segments allowed it
to programm with all the advantages of a mature OS.
Indeed... Minix was a pretty
good example of how we used and
abused that to no end, in a somewhat PDP-11 style in the sense
that we didnt (by default ;-) provide the process with a method
to claim more of those segments, so the process space was the
usual 16-bit deal.
However, we did change this and added "large program" support
to it, allowing for what DOS used to call "large" and "huge"
memory models. The nasty part of that project wasn't the
kernel, but the compiler. We ended up cross-compiling such
programs under DOS (with Borland C *grin*) and then move them
over to the Minix machine.
So.. we have a real-mode CPU, 16-bit addressing space, and
yes, we could use lots of memory.
The only thing missing where page faults and boundry
checks. The 286 then added these features.
Erm, yeah. You could poke into random
segments, admitted,
and there was no way to do demand paging since the hardware
didnt support mapped-out pages, which indeed the 286 did,
and which someone (I believe Bruce Evans) added to the
system for Minix/286 which added this "protected mode".
HOWEVER: this is memory management done actively, by the
user program itself, since it has to keep track of what
is where (keep a segment table in the process).
Let's not go into how 286 and 386+ protected mode memory
management works, since that is WAY offtopic.
I like both (PDP11 and 8086) ways of memory management, and
they both served their purpose, imho.
Fred (trying to get the !@#&*%@#$^ DECstation to boot OSF/1)
--
Fred N. van Kempen, DEC (Digital Equipment Corporation) Collector/Archivist
Visit the VAXlab Project at http://www.pdp11.nl/VAXlab/
Visit the Archives at http://www.pdp11.nl/
Email: waltje(a)pdp11.nl BUSSUM, THE NETHERLANDS / Sunnyvale, CA, USA