Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!hsdndev!spdcc!iecc!Postmaster
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Real 46 Bit Addressing in the 386/486!!!
Message-ID: <9012022236.AA07074@iecc.cambridge.ma.us>
Date: 3 Dec 90 03:36:13 GMT
Sender: Postmaster@iecc.cambridge.ma.us
Organization: I.E.C.C.
Lines: 23
In-Reply-To: <17945@netcom.UUCP>

In article <17945@netcom.UUCP> you write:
>[mark extra data segments as not available and emulate instructions that
>reference them]
>This method permits the use of almost all data segments except stack
>segments as 32 bit segments; it is a *little* slower than the previously
>suggested hardware modification ...

A little slower, huh?  On a 486, an add from memory, a typical memory
reference instruction, takes 2 cycles.  Just the trap on a page fault takes
about 100.  In fact, what you're proposing is the same as loading and storing
your data via a system call, and it's at least two orders of magnitude
slower than normal loads and stores.

Any scheme that tries to provide more than 32 bits of VM on a 386 or 486 is
doomed to terrible performance, because you have to take traps and get the
operating system involved each time you refer to some of the overcommited
memory.  The only thing I can see that has any chance of working is to allow
each segment to grow to 29 bits, since that way you can always easily map all
6 addressable segments, put each file or whatever in a segment, and use
relatively infrequent segment loads analogously to file opens.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Brought to you by Super Global Mega Corp .com