Bob La Quey wrote:
On 10/7/07, Tracy R Reed <[EMAIL PROTECTED]> wrote:
Gus Wirth wrote:
They also happily run 16-bit code, aka DOS. Backward compatibility has
been remarkably preserved across the entire x86 line.
At tremendous expense in chip real-estate and power consumption. I
recall Andrew Lentvorski telling us all about it at Denny's one evening.
--
Tracy R Reed
Hmm ... I wonder why that would be so? Whay could the older
designs not be simply emulated in a layer of software? Andy?
There are two issues going on. Software and hardware.
First, the software:
You could run in emulation, but what does a computer running 16-bit code
look like?
That answer is "bare DOS".
Nowadays, this probably isn't such a big deal. Windows comes
preinstalled on practically every new computer, and Intel could probably
punt the emulation to Microsoft. This, of course, wasn't the case when
16-bit code mattered.
In addition, the fact the CPU's are now so fast compared with any
generation in which 16-bit code matters (which assumes much closer
CPU/memory latency rations) makes performance loss a moot point.
However, it took until probably the Pentium III 700MHz+ where software
emulation could perform better at 16-bit code than a Pentium 133 or a
Pentium Pro 200 (which was probably around the last generation where it
mattered) .
Second, the hardware:
16-bit code *sucks*. It does a lot of nasty things. Practically all of
them require that you turn off all the useful performance enhancements
of modern microprocessors.
Decode is unaligned and requires looking at multiple bytes to determine
how many bytes to fetch. Not a big deal when you actually fetch 1 byte
at a time. A much bigger deal when fetching single bytes is
*expensive*. So, you tend to overfetch to make sure that you get enough
bytes to handle the decode in one shot.
This, of course, causes issues with prefetching parts of memory that may
not exist. You can get extraneous traps, pages mapped only to go
unused, cache evictions that are unused, etc. Avoiding these requires
lots of hits to all your superscalar logic.
And, I haven't even mentioned things like self-modifying code or
denormal floats (AutoCAD used to rely on undocumented behavior) and
other nastiness.
Getting *all* of this right required a lot of computation if it was only
in software. The fact that VMWare has really only become useful in the
last year or two is a testament to how fast CPU's have gotten, how much
time a CPU normally spends idle, and how good the VMWare code has
finally gotten.
Before this, the only real option was to bury a bunch of this in the
hardware with all the attendant incursions into your nice clean
superscalar pipeline.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
