Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!apple!usc!cs.utexas.edu!uunet!world!iecc!johnl
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Let's pretend
Keywords: Intel, 586, windows
Message-ID: <1990Dec19.060521.16051@iecc.cambridge.ma.us>
Date: 19 Dec 90 06:05:21 GMT
References: <3042@crdos1.crd.ge.COM> <1990Dec18.082623.16648@kithrup.COM> <3058@crdos1.crd.ge.COM>
Organization: I.E.C.C.
Lines: 54

In article <3058@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  I think we can assume that the 586 will be a superset of the 486.

Indeed.  It seems to me pointless to add new features to the user-mode
instruction set.  There are enough 386 and 486 chips around that no sane
programmer would use the new features, the gain would be unlikely to be worth
losing backward compatibilty.  Rather, we need either features that
transparently improve performance, or else features that are a big enough win
that it's worth forsaking backward compatibility.  Here are a few
suggestions:

-- Per-segment paging.  As has been beaten to death here before, the current
paging scheme limits the total address space of a process to 4GB.  With a
page table per segment, you actually could map each open file to a segment
(a 4GB file is still pretty big) and merge all I/O with virtual memory.

-- Better segment performance.  On the 286, 386, and 486 it takes forever to
load a segment register.  On the 486 it takes 9 cycles, compared to 1 cycle
for a regular memory load.  Perhaps it could cache a dozen or so recently
loaded segment numbers.  The FS and GS registers are no substitute, nobody
has the faintest idea how to manage segment registers separately from
address registers.

-- (My favorite.)  Better interrupt performance.  There are two problems.
One is that interrupts are just plain slow.  A normal interrupt takes 71
cycles, but if you use the facility to run an interrupt in its own task, the
interrupt takes 236 cycles.  The return takes 231.  I know it's doing a lot
of work, but get real -- that's close to 20us for a null interrupt handler on
a 25MHz part.  Some lighter weight interrupts, perhaps assisted by multiple
register sets, would be nice.  Also, device interrupts on the 486 use the
same creaky method that the 8088 did.  There's a single interrupt line, and
when the interrupt happens it accepts a vector from the interrupt controller.
That controller is still an 8259A which only has 8 interrupt lines unless you
cascade them which is a kludge.  There is no easy way to mask some device
interrupts without masking them all (you can stuff commands to the 8259 but
it's slow and clumsy.)  An interrupt level register that the kernel could
manage easily, sort of like the PDP-11 scheme, would be helpful.  To support
this without having a dedicated interrupt line for each device needs a bus
protocol so that devices can post a request for interrupt including the
interrupt number, and the CPU can come back later and say "number 17, your
interrupt is now taken."  If we have all level-triggered interrupts, we could
even get by without the call back.

-- Graphics support of various kinds.  The 860 has a little support for
ray tracing, with some instructions that make it easy to whiz through your
data structures and figure out what obscures what.  One might also like some
support for bit-aligned bit-blits, though that tends to tie up the data bus
and so would be far more useful if it had some separate path to memory, at
least to video memory, that didn't lock out the CPU.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Typically supercomputers use a single microprocessor." -Boston Globe