Recently, I have seen some Intel advertisements claiming something
close to a 2-to-1 speed advantage for the 8086 (or '186 or '286) over
the 68000. Having used both C and assembler on both, at one time or
another, I find this hard to believe. The 68000 seems inescapably
superior in performance.
Does anyone know the real story on this? Certainly, for floating
point Intel has it made. But for anything else?
Michael Turner
However, the 8086 instruction set does turn out to be rather
more bit efficient than the 68000's for the cases the 8086 can
handle. Notably, 64K max address space needed for any single purpose,
most operations involving characters or simple 16bit integer arithmitic,
not much in the way of pointers, arrays, etc. AND the 8086 has a
very nice floating point chip.
One can, for instance, write very good BASIC interpreters for
the 8086.
The 8086's trouble is that compilers have a lot of trouble generating
good code for it and its limits get hit very early in a lot of new
applications. INTEL keeps saying, quite correctly, "Hey, guys, the
8086 is better at the things all micros can do." To which the general
reply outside the "commodity PC market" is "but we can't afford to do
new things on it." In short, "technically obsolete."
(Cheer up INTEL: DEC hears the same things about the PDP-11, which
has a much nicer architecture.)
Mark Swanson
...decvax!genradbolton!gkermit!marks
a) The comparison is between an iAPX286 and a M68000. By Intel's own
admission, an iAPX 286 is 3 times as fast as an iAPX 86 (8086)
at the same clock speed.
b) In the add the 68000 is .28 to .49 of the 286, so it is indeed faster
than an 8086.
c) In the ad, note the bus speeds: The iAPX 286 is cycling the bus every
2 clock cycles (i.e. 250 nanoseconds / bus cycle) while the M68000
is cycling the bus every 6 clock cycles (i.e. 750 nano-seconds).
d) The reason for c) is that the M68000 is assumed to use a M68451 which
imposes (in their calculations) 2 wait states on the M68000. As is
demonstrated by the SUN boards, with a clever memory management scheme
you don't need to impose wait states.
e) From d) you can multiply the numbers given for the M68000 by 1.5,
or from c) you can multiply the numbers by 3.0 if you assume equal
bus cycle times.
f) Note that a 250 nanosecond bus cycle is awfully fast to keep up,
typically you add some overhead to the basic cycle times of dynamic
RAMS in getting the data to the bus or off of it.
g) More importantly, the comparisons don't deal with any benchmarks which
need to access large arrays, for example a 1024x1024 display bitmap
which is 2 to the 17th bytes large. Note that the Intel iAPX 286
can't directly address that large a space, it must load and unload
segment registers, while the M68000 could directly address it.
h) As always, let the reader beware (caveat lector?)
Rich Hammond
As far as the 286 is concerned, as of this date, nobody's even seen a fully
functional one. The A-step samples out do not have the memory managment
working yet and there are some pretty strange things happening with interrupts.
And the darned thing won't run correctly with interrupts at 8 Mhz; you have
to decrease the clock speed to about 7.5 Mhz. Intel's due to sample the
B-step parts later on this month.
By the way, the 80287 doesn't interface to the 80286 the same way that
the 80187/80186, 8087/8086 combinations do. What with all that memory
management logic onboard the 286, the 287 can't know when the MMU registers
have been changed. So the 287 operates on an I/O port. This undoubtedly
will have some effect on the timings.
It was my impression that this advantage was claimed as a result of benchmarks
that don't use the linear addressing of the 68k; that is, that run in 64k
or less. Frankly, I don't really believe it even in those cases.
If anyone has any of the benchmarks and the results, please post.
Mark Wittenberg
...!decvax!sytek!zehntel!mark