Article View: net.arch
Article #2881Re: Reasons For Large Main Memories
From: aglew
Date: Wed, 17 Sep 1986 15:15
Date: Wed, 17 Sep 1986 15:15
47 lines
3058 bytes
3058 bytes
... > Large main memories... Scientific codes can effectively do their
... > own memory management, and do not need to be penalized by VM HW.
J. Giles et al have pretty much persuaded me that virtual memory isn't
always a good thing (it wasn't hard - I was already there).
But, unless you are selling computers strictly to the non-virtual scientific
crowd, a computer manufacturer will probably want to have virtual memory for
his general purpose customers. Your market offering might run like this:
1. A general purpose machine/OS with virtual memory
1'. The ability to turn off virtual memory in machine/OS 1,
for efficiency of important scientific codes.
2. A strictly scientific machine that doesn't have virtual memory
hardware at all, so scientific codes that don't use virtual
memory pay no penalty at all.
Assumption: you will probably want these machines to be architecturally
compatible, to save development cost for peripherals and assembly language
code, and so that marketing can tell customers that you have a binary
compatible family of machines... (sigh).
Q1: What features should a machine have so that it can span both virtual and
non-virtual systems?
Q2: In the non-virtual, scientific, machine 2 do you really want to be
running a multi-tasking system?
Q3: In a multi-tasking OS, can you mix virtual and non-virtual processes?
If the answer to Q2 is no, you're running a batch system, and you don't
need much special support in the instruction set, at least, to span virtual
and non-virtual systems. Same thing even if you are doing batch style
multitasking, so long as you don't need to swap processes out and move
them around in core.
What if your customers' answer to Q2 is yes? (Cray seems to think so, with
their UNIX). If you need to swap processes out and dynamically relocate them
in core, what IS features do you need?
I think this question was answered a long time ago - base registers.
Now, my real question is what exactly you need to make base registers useful.
Any takers?
I'm not sure that Q3 is an important question. You're only going to mix
virtual and non-virtual processes if there is a speed advantage to be gained
by turning off translation. Ie. running with the identity map would be
equivalent, except for TLB misses.
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
Technical Details
Message-ID:
<5100134@ccvaxa>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!columbia!caip!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglewReferences:
<8494@duke.duke.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!columbia!caip!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.arch Subject: Re: Reasons For Large Main Memories Message-ID: <5100134@ccvaxa> Date: Wed, 17-Sep-86 11:15:00 EDT Article-I.D.: ccvaxa.5100134 Posted: Wed Sep 17 11:15:00 1986 Date-Received: Sat, 20-Sep-86 01:41:21 EDT References: <8494@duke.duke.UUCP> Lines: 47 Nf-ID: #R:duke.duke.UUCP:8494:ccvaxa:5100134:000:2440 Nf-From: ccvaxa.UUCP!aglew Sep 17 10:15:00 1986