Hans and Eric write about memory management.
Hans now comments:
> > 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).
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.
> 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 !_at_#&*%@#$^ 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_at_pdp11.nl BUSSUM, THE NETHERLANDS / Sunnyvale, CA, USA
Received on Fri Nov 14 2003 - 07:58:51 GMT