Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

68k vs. 8086 - (nf)

487 views
Skip to first unread message

ucbesvax!turner

unread,
Feb 17, 1983, 2:01:52 AM2/17/83
to
#N:ucbesvax:5900001:000:456
ucbesvax!turner Feb 14 20:38:00 1983


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


grkermit!marks

unread,
Feb 17, 1983, 2:03:29 PM2/17/83
to
As for the INTEL claims of 2:1 speed advantage over 68000:
it depends. What speed 8086/80186/80286 vs 68000 do you regard
as normal?

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

npoiv!rah

unread,
Feb 17, 1983, 10:49:25 PM2/17/83
to

I assume that you are talking about an ad such as is on page 171 of
the Feb. 10th "Electronics." You have to read the fine print.

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

amd70!pn

unread,
Feb 17, 1983, 11:47:47 PM2/17/83
to
Are you talking about the 68K vs 286 ads? I understand the 286 is heavily
pipelined, accounting for its better performance. In addition, memory
management is integrated on-chip, avoiding the delay most 68K systems
suffer. A 10 MHz 286 can save the state of a task (all registers),
load the state of another task, and resume execution in less than 17 uS.
The operating system support, memory protection and management all look
rather nice. The only thing I don't like is 64K data segments.

fortune!guzis

unread,
Feb 19, 1983, 11:14:40 PM2/19/83
to

The one thing the 80186 has really going for it is the simplicity of inter-
facing more than anything. With 2 DMA channels and 4 timers and 6 programmable
chip selects onboard the chip, we'll doubtless see quite a few products using
it. And yes, Intel has reworked some of the instructions, most notably the
multiply (35 clocks on the 186, vs. 70 on the 8086).

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.



tekid!kevenb

unread,
Feb 20, 1983, 2:49:53 AM2/20/83
to
Don't be so sure that nobody has seen 286's working yet.

wb2!tcb

unread,
Feb 20, 1983, 2:58:05 AM2/20/83
to
CPU speed is one thing while system design is another. You can have a damn fast
cpu and - as we have seen it at the UNICOM - some poor architectural designs.
What is VERY good about the 86 CPU is that it is a member of a FAMILY of chips
with good architectural qualities. As far as floating point is concerned,
many hackers out there down-play its importance. They shouldn't. In many
serious applications a fast floating point unit is the only road to success;
just think of graphics, simulation, numerical analysis, banking etc.
received data 709 bytes 9 secs

zinfandel!mark

unread,
Feb 21, 1983, 1:34:18 AM2/21/83
to
#R:ucbesvax:5900001:zinfandel:8000002:000:332
zinfandel!mark Feb 18 12:07:00 1983

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

0 new messages