🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2881

Re: Reasons For Large Main Memories

#2881
From: aglew
Date: Wed, 17 Sep 1986 15:15
47 lines
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!aglew
References: <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