bzs@ENCORE.COM (Barry Shein) (12/20/88)
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||
asp@puck.UUCP (Andy Puchrik) (12/21/88)
In article <8812200325.AA12574@multimax.encore.com>, bzs@ENCORE.COM (Barry Shein) writes: > 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? The ever-popular MIPS R2000 has a 4Gb address range, but the address space is divided into 2 Gb for users and 2 Gb for the kernel. The TLB (Translation Lookaside Buffer) gives each user up to 2 Gb of virtual address space. -- Internet: asp@puck.UUCP Andy Puchrik uucp: decvax!necntc!necis!puck!asp Moonlight Systems ARPA: puchrik@tops20.dec.com Concord, MA 01742
Makey@LOGICON.ARPA (Jeff Makey) (12/21/88)
In article <8812200325.AA12574@multimax.encore.com> bzs@ENCORE.COM (Barry Shein) writes: >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. Be careful not to confuse virtual addresses with physical addresses. For example, the VAX architecture gives you the use of 1.5 * 2**31 bytes of virtual space, but only 2**30 bytes of physical memory. >The remaining question is, 48 bits or 64 bits for the next >generation? Virtual addresses: Given that very few computer programs (I said, "few." I don't want to hear about *your* monster program!) are capable of making good use of an entire 32-bit virtual address space, I suspect that 32-bit addresses are a good tradeoff between addressing capability and program size (change virtual addresses to 64 bits and *every* pointer in your program doubles in length). Certain applications (generally, scientific ones I would imagine) will want larger virtual addresses; that's what supercomputers are for. Physical addresses: It would be nice to have an architecture that would support really large amounts (48 to 64 bits worth) of physical memory, but -- once again -- most applications won't need them so I would expect different hardware configurations of the same architecture to support different amounts of physical memory, with the larger capacities costing more. One practical limit to physical memory size is the time required to transfer data to/from mass storage (e.g., disk). Demand paging helps keep this under control, but you're going to be annoyed when it takes minutes (!) to write your gigabytes of memory out to disk at the end of the day (battery backup of memory should be standard to avoid problems with powerfailures). Also (and I hope this is obvious!), more memory than mass storage space is a questionable configuration, at best. Will mass storage tecnology be the computing bottleneck of the future? To summarize, I feel that 32-bit demand-paged virtual addresses are a central part of an architecture that will satisfy at least 95% of all applications for the next 10-15 years. Systems that run lots of *big* programs will need to be able to map these 32-bit virtual addresses into maybe 48 bits worth of physical memory. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
dan@WATSON.BBN.COM (Dan Franklin) (12/22/88)
> ... Anyone know what the address space is for the RISC processors > which are becoming so popular? I don't know if the RISC chip set inside the RT PC would qualify as "popular", but as I recall, its physical address space is 43 bits. (The top 4 bits of each 32-bit virtual address choose one of 16 segment registers; segment registers are 15 bits wide. Thus the segment address + 28-bit offset gives 43 bits.) I think the current line may only bring out 12 of those 15 bits, so the current implementations may be restricted to 40 bits. Dan Franklin
bga@raspail.UUCP (Bruce Albrecht) (12/22/88)
CDC Cyber 180's in native mode have up to 2**12 segments of 2**32 bytes, giving them an addressing space of 2**44. Disk files are actually memory segments, reads and writes are handled as page faults. I'm not sure if they support files larger than 2**32 bytes, yet, because that would require the files to span segments.
jbn@glacier.STANFORD.EDU (John B. Nagle) (12/23/88)
Eventually we have to get away from addressing memory by dense
numbers and go to a naming architecture. Addressing by pathname is
a distinct possibility. This idea is not new; it first appeared in
the Burroughs 5000 and English Electric Leo Marconi KDF-9, circa
1960. But the memories of the day were not large enough to really
require such an architecture.
Now that we're getting there, something like this starts to
make sense. Imagine addresses that look like UNIX pathnames. At
the lowest level, one has an object that is addressed sequentially,
like a UNIX file. But in general, sequential units would be single
arrays, or at least no larger than the workspace of a single named
object.
Efficient implementation of this concept is quite possible. It
requires segment registers and cacheing.
One thing worth realizing, by the way, is that ferroelectric RAM
technology is coming. Some, perhaps most, 16Mb RAMs will be nonvolatile.
The implications of nonvolatile main storage are interesting. There
are both good and bad points to this. Among other things, virus
eradication may become very difficult in an era when clearing RAM is
as traumatic as reformatting a hard disk.
John Naglesmryan@garth.UUCP (Xxxxxx Xxxx) (12/24/88)
>CDC Cyber 180's in native mode have up to 2**12 segments of 2**32 bytes, 2**31 bytes, sign bit must be zero. > I'm not sure if >they support files larger than 2**32 bytes, yet, because that would require >the files to span segments. Yes. yes. The Cyber 205 has 48 bit vitual bit address, or 2**45 bytes. Rumour has if you buy enough disks and memory to complete the address space, they'll throw in a 205 for free. -- An otter ate beside the rush -- s m ryan with blinking eyes beneath a bush. He closed his eyes to hide the thought -- Andwari's Gem the salmon soon would be as naught. -- 1/3
janssen@titan.sw.mcc.com (Bill Janssen) (12/30/88)
Remember that the PDP-11/34 type of machine had more physical memory, 128KB, than program address space, 64KB. The PDP-11/70 addressed this problem with separate I&D space. Virtual memory makes the size of physical memory less important. When the amount of physical memory goes above the sum of the virtual memory requirements of all the processes, don't add any more. The real restriction on program size seems to be imposed by swap partitions. Anybody running a 500MB swap partition? (Mine is 150MB). Bill
fbaube@NOTE.NSF.GOV ("F.Baube") (12/31/88)
With the advent of cheap non-volatile RAMs (such as ferro- electric), isn't there an operating system design issue relating to whether the dichotomy of core memory versus device-based storage isn't a bit artificial ? Is there an OS that can run a program without first loading it, by applying (virtual) program addresses directly to the device that has been determined to be byte addressable ? To rephrase, why should an executable stored in a RAM disk first have to be copied to main memory in order to be executed ? Pardon me if this is an old question.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/04/89)
In article <8812301210.aa25361@note.nsf.gov> fbaube@NOTE.NSF.GOV ("F.Baube") writes: > >With the advent of cheap non-volatile RAMs (such as ferro- >electric), isn't there an operating system design issue relating >to whether the dichotomy of core memory versus device-based >storage isn't a bit artificial ? Is there an OS that can run a >program without first loading it, by applying (virtual) program >addresses directly to the device that has been determined to be >byte addressable ? To rephrase, why should an executable stored >in a RAM disk first have to be copied to main memory in order to >be executed ? > >Pardon me if this is an old question. Consider the IBM mainframe extended storage options, or the Cray solid state disk (common on XMP systems). Both these system's lack the hardware support for enough memory, so the RAMdisk is very different that real memory. Cray does not support any sort of VM, so the RAMDISK is really just that (albeit very, very fast). IBM does support VM (the OS and the memory system :>), there are several levels of memory (2 levels of cache on some) followed by real memory (RAM), followed by extended storage (which can only be spoken to in special ways) followed by actual disks (and often these are tiered w.r.t. performance). There is a large overhead in dealing with overhead memory, so fetching (or writing) byte by byte would be a very bad move. With today's machines the different memory systems have very different characteristics. Loading the program into system memory and then paging out what turns out to not be useful works out fairly well. Demand paged systems do pretty much what you suggest, in that "loading" is very short, execution begins, followed (in nearly all cases) a page fault, which results in some IO, followed by some exeuction, etc. There was a very cheap 16032 kit for the PC and z80 machines which used this form of demand paged memory, and it worked out fairly well. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus