Dave McGuire wrote:
And you do realize "PDP-11" spanned some two
and a half decades and
more
than a dozen implementations with a huge range of processing power
ranging from "wimpy" to "big clanging brass balls", right?
Yes, but the PDP 11 was designed to have raw power from the original
design. OK, they goofed on a basic address space of 18 bits.
16 bits, actually. The two MMU architectures extended that to 18 and
22 bits. I wouldn't call it a goof considering the first one came
out in 1970. For a small lab minicomputer in 1970, 64KB isn't bad at
all.
Considering the cost of CORE memory in 1970, 64KB was
much larger than any PDP-11 at that time. 8KB was a
common system. Even up to around 1975, I don't think
there was an MMU available in any case. Does anyone
know when the MMU was first used with more than 64KB
of memory for the system?
As for total memory available to use for temporary
work space, when I run Ersatz-11 under WXP on a
system with 4 GB of physical memory (I agree that
WXP wastes almost 1 GB of that memory), Ersatz-11
allows me to provide a program running on what looks
like a PDP-11 with access to about 1.2 GigaBytes of
temporary storage work space. The words are accessed
via 4 IOPAGE registers, the third and fourth registers
being a 32 bit byte address. The access time is up
to ten times the access time to emulated PDP-11 program
data within the normal 64KB, but that is MUCH faster
than using other methods such as VIRTUAL in FORTRAN,
let alone the size limitation with the latter method
of 4 MegaBytes. In addition, it is possible to
enhance the DLL which is used to access that extra
1.2 GigaBytes and have the DLL perform a substantial
portion of the data manipulation. It would be very
similar to adding a co-processor to the PDP-11 which
I have using in the past to calculate FFTs and other
vector quantities.
Of course, no one would ever start a new project using
Ersatz-11, but for current projects that have a major
investment in software, using Ersatz-11 is often a
very low cost solution to increased CPU and disk I/O
speeds.
Sincerely yours,
Jerome Fine