Various wrote: > From: Otto Moerbeek <[EMAIL PROTECTED]> > To: Ted Mittelstaedt <[EMAIL PROTECTED]> ... > > What was the bit size of the CPU's originally used to write UNIX in Bell > > Labs? > > What's more, iirc the MMU of the pdp11 isn't what we call a MMU today, > it could not even do paging.
The pdp-11 mmu could handle program relocation, segmentation (after a fashion) and memory protection. I'm not sure what more you could expect from an mmu. What you mean by "paging" is probably "demand paging", which means the ability to run a program without requiring that it be entirely resident. The key feature you need for that is a guarantee that any instruction fault caused by missing memory can be either restarted or continued. In most architectures that's a question of cpu design not mmu. In the case of the pdp-11 that's mostly a moot point. The pdp-11 only provides for mapping the 64k of memory space into into 8 segments (addressable on 64-byte "clicks") and there's just not much win to demand paging 8 "pages". (actually 6 x 8 pages; there was kernel, user, and supervisor mode, & each had separate instruction and data spaces, but supervisor mode was rarely used in Unix environments, and only a few large user mode programs ran using split I/D space.) For what it's worth, though, I *think* it was possible to restart most instructions on the /45 and /70, which were the "big" machines and the primary target of most later pdp-11 work. In fact, some use was made of this feature -- automatic stack growth. If you look through ancient Unix source, you'll find interesting bits of kernel code that manage this. There's actually a cheesy way to do demand paging with microprocessors that don't support demand paging (such as the original 68000--another "16 bit" machine). The way to do this is to run two processors in parallel but skewed by one instruction. If the first one does a bad memory fetch, then the second one will not have fetched the instruction causing the fault so contains restartable machine state. Masscomp sold a machine like this once. -Marcus Watts _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"