Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!ENCORE.COM!bzs
From: bzs@ENCORE.COM (Barry Shein)
Newsgroups: comp.society.futures
Subject: Memories...
Message-ID: <8812200325.AA12574@multimax.encore.com>
Date: 20 Dec 88 03:25:07 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 60


A few weeks ago I posted a note from Computerworld about NEC investing
in a 16Mbit DRAM production facility. I started doing some arithmetic
and it suddenly occurred to me that we may be on the verge of the
other side a memory problem, too much?!

32MB and 64MB single boards manufactured from 1Mb DRAMs are relatively
common today in medium-sized systems. If the supply leap-frogs to 16Mb
then those become 0.5GB and 1.0GB respectively.

The address space on most CPUs today is 32 bits (hmm, for arguable
values of "most", well, very common anyhow.) In fact, it's usually a
little less, 31 bits is often all you can use. That's 2GB or two or
four of those boards, not a whole lot. Then bango, you're full up,
can't use anymore physical memory. Anyone know what the address space
is for the RISC processors which are becoming so popular?

At that point vendors have two choices, change CPU architecture
(relatively painful) or find some sort of workaround.

For typical workarounds we can look to the past, there are two major
versions which have been used (with various variants):

1. Separate I&D space (a la the PDP-11), instructions are stored in
one address space and data is stored in another thus doubling the
theoretical address space (although I suspect needs are assymmetric
with data running out long before instruction space.) This works by
the CPU fetching instructions relative to one address space and then
fetching the data they refer to from another, fairly simple.  Unix
still has some scars from coping with those days (was nargs() a victim
of separate I&D? I don't remember.)

2. Allowing (eg) 31 bits per process but being able to have many of
those in memory at once, a context switch now involves switching a
bank register to extend the memory being addressed (a relatively
painless architecture extension which only the O/S will see.) I
believe OS/370 has used this approach, probably others (PDP-10?)

This is fairly transparent but of course still allows one only the old
address space worth of memory (it only enhances multi-processing by
minimizing access to secondary storage.) Of course, in this day and
age it will be user processes which want the memory, in many instances
simple time-sharing is becoming less important, this doesn't work.  I
would imagine it also makes sharing physical pages between two such
processes nearly impossible (?)

Hybrids of these two schemes are of course possible, they're not
mutually exclusive. Other temporary possibilities are to do things
like use the extra memory as ram disks etc, I consider that begging
the question.

Fortunately we live in a more (software) portable world and new
processors won't be the end of the world although I have no doubt
there will be a fair amount of pain going to longer pointers, programs
which make assumptions etc.

The remaining question is, 48 bits or 64 bits for the next
generation?

	-Barry Shein, ||Encore||