[net.micro.68k] 68vs86

steve@kontron.UUCP (Steve McIntosh) (06/17/85)

            68000 family .vs. 8086 family processors
		      One Hackers Opinion

Lately, there has been much traffick over the net concerning the
relative merits of the Intel 8086 family of processors and the Motorola
68000 family of processors. 

This brings back memories of the old 6502 .vs. Z80 arguments that kept
many people fighting one another over what amounted to a religious war.

Simply put, comparing the two families is like comparing apples and
oranges (or Mac's and PC's). The two microprocessor families were
targeted at different markets. The 8086 family at the business market
(bean counters) and the 68000 at the scientific market (electron
pushers).

Further, the 8086 family was designed with multiple users in mind, so
that a whole corral of bean counters could (eventually) use the same
machine or one bean counter could count several different colors of
bean at one time.

The 68000 was designed with crunching numbers and pushing electrons
around at the maximum speed. For ONE electron pusher.

This is much the same division as the Z80/6502 dogma. The Faithful
Newsletter Editor of DTACK grounded has compared the 8086 family to a
large truck designed to transport many sheep, each in it's own segment
(er.. stall) while the 68000 family is likened to a Ferrari that will
get one person somewhere FAST. 

Which thing do you want to do? A Ferrari won't get many sheep to
market, and a large truck will not get anything anywhere fast. Apples
and oranges - the best processor for an application depends on the
application itself.

I feel that most of the confusion on the net is that the 8086 family is
much more in tune with the objectives of many of the people on the net
who don't consider a computer a REAL computer unless it can multi-task
ala UNIX. The 68000 often loses its speed advantage when forced to do
task switching or is crippled with a memory manager. 

Most of the people on the net want to crunch numbers or do other exotic
non-bean type activities, and so are attracted to the 68000. However,
they also want all the bells and whistles of UNIX, which the 68000 was
not really designed for. 

And the religious war continues, only it is now a 16/32 bit war instead
of just an 8 bit war.

I would be interested in seeing various people defining their NEEDS and
then discussing which processor fits the need and not the want.

		     == Entering Flame Zone == 

Personally I would rather drive a suction truck and vaccuum portable
toilets than write assembly language code for the 8086 family. However
there is a lot of money to be made driving a vaccuum truck. The 68000
on the other hand is a joy to write assembly code for. Not being a
compiler writer, I can understand and appreciate the trade-off's that
were made in the 68000 instruction set plus the bonus of all those
registers!

Also, as I was hacking back in the Dark Ages of Microcomputers (the
early 70's) multi user/tasking systems seem to be a giant step
backwards to the old mainframe mentality. I can see interleaving a CPU
intensive task (like a compiler or assembler) with an I/O bound task
(like an editor) and a couple of interrupt sources to run a knee-jerk
print spooler, but going beyond a simple foreground/background system
seems to be overkill - and degrading (of the system, that is.)

But enough of my personal gripes. The world is big enough for all types,
and those of you who crave standards or the One True Processor aren't 
going to change the way the market works so:

== Flame Off ==

The ravings expressed in this posting are personal and should not
be taken as being in accord with any other person, or any company.

guy@sun.uucp (Guy Harris) (06/20/85)

> The two microprocessor families were targeted at different markets. The
> 8086 family at the business market (bean counters) and the 68000 at the
> scientific market (electron pushers).
> 
> Further, the 8086 family was designed with multiple users in mind, so
> that a whole corral of bean counters could (eventually) use the same
> machine or one bean counter could count several different colors of
> bean at one time.
> 
> The 68000 was designed with crunching numbers and pushing electrons
> around at the maximum speed. For ONE electron pusher.

Can anybody from Intel and Motorola back these claims up, or are they just
speculation?  I suspect both chip families were designed for anybody who'd
buy 'em.  The 80*2*86 may have an MMU on-chip, but the 8086 doesn't, so it's
no more "designed with multiple users in mind" than the 68000 was.
Furthermore, Motorola has come out with two MMU designs for the 68000 family
- why would they have done so if they intended it for single-tasking systems
only?

> Also, as I was hacking back in the Dark Ages of Microcomputers (the
> early 70's) multi user/tasking systems seem to be a giant step
> backwards to the old mainframe mentality. I can see interleaving a CPU
> intensive task (like a compiler or assembler) with an I/O bound task
> (like an editor) and a couple of interrupt sources to run a knee-jerk
> print spooler, but going beyond a simple foreground/background system
> seems to be overkill - and degrading (of the system, that is.)

Please don't combine the two phrases "multi-tasking" and "multi-user"
into one.  They are two separate things.  My workstation can run multi-user
(if somebody wants to "rlogin" to it), but isn't intended to be used that
way.  It does support many tasks, though, and I'm damn glad for that.  I'm a
multitasking system - my computer should be also.  (I have one window
monitoring mail, one displaying the current time, one displaying a graph of
CPU utilization, one remotely logged in to "sun", one waiting to remotely
log into another machine, and another one giving a shell on my own machine.)

As for "degrading the system", our MMU adds no wait states.  Yes, the OS
imposes more overhead because it's a multi-tasking OS - but I sincerely
doubt that running a single-tasking OS would make this machine enough faster
that it'd be worth sacrificing the convenience of having multiple active
windows.  (You might be able to cut down on some of the overhead by running
an OS that supports multiple tasks but provides minimal protection; it might
run all processes in one common address space.  Of course, FNE wouldn't like
an example that comes to mind because it's written in Mesa, not assembly
language...)

	Guy Harris

sjl@amdahl.UUCP (Steve Langdon) (06/20/85)

> 
>             68000 family .vs. 8086 family processors
> 		      One Hackers Opinion
...
> Simply put, comparing the two families is like comparing apples and
> oranges (or Mac's and PC's). The two microprocessor families were
> targeted at different markets. The 8086 family at the business market
> (bean counters) and the 68000 at the scientific market (electron
> pushers).
Followed by more text extending this analogy.

I strongly disagree.  Both were designed to get as much of the total
market as they could.  However, Intel thought that a measure of 8080
compatiblity and a quick design cycle was the correct approach, and
Motorola (with a smaller 8 bit base) choose to do a completely new
design (except for the funny stuff that let you use 6800 peripheral
chips).

Intel's real stroke of genius was to get the 8088 out soon after the
8086.  This allowed a machine with an 8 bit bus to achieve many of the
advantages that would otherwise have required a more expensive 16 bit
bus.  This of course led to the use of the 8088 in the IBM PC, and
the large user base that the 8086 family now enjoys.

Some of us still remember that the 432 was meant to be Intel's high end
micro product.  Fortunately for Intel, the 8086 family was strong enough
to pick up the pieces when the 432 sank like a lead balloon.

I also disagree with the idea that the 68000 was not designed for
operating systems like UNIX (tm).  The 68000 has a reasonably clean
minicomputer style architecture which is precisely the environment that
UNIX was born in.  The importance of good memory management hardware
has only recently become obvious to the microprocessor manufacturers.
Motorola's first attempt (68451) was inadequate and Intel have yet to
offer something suitable for demand paged virtual memory.  This has
left National with the good fortune of being the only supplier of a
chip set that will do most of the things needed for a computer system
that supports virtual memory.

I am happy to see the competition continue, as it will result in better
computers.
-- 
Stephen J. Langdon                  ...!{ihnp4,hplabs,sun,nsc}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

steve@kontron.UUCP (Steve McIntosh) (06/24/85)

> 
> Please don't combine the two phrases "multi-tasking" and "multi-user"
> into one.  They are two separate things.  My workstation can run multi-user
> (if somebody wants to "rlogin" to it), but isn't intended to be used that
> way.  It does support many tasks, though, and I'm damn glad for that.  I'm a
> multitasking system - my computer should be also.  (I have one window
> monitoring mail, one displaying the current time, one displaying a graph of
> CPU utilization, one remotely logged in to "sun", one waiting to remotely
> log into another machine, and another one giving a shell on my own machine.)
> 
> 	Guy Harris

Notice that most of what you point out as the desirable qualifies as simple
monitor tasks. And at that you are obviously aware of how much "horsepower"
these tasks take up - you run a utilization monitor. I have no doubts that
such systems will be the "wave of the future", but if I can't turn it off
when I want my machines full attention on something I consider important,
I'd rather not have it. [ Personal peeve ]

Also, the FNE has wondered about me, too... My programming language of
choice is FORTH.

guy@sun.uucp (Guy Harris) (06/26/85)

> > (I have one window monitoring mail, one displaying the current time, one
> > displaying a graph of CPU utilization, one remotely logged in to "sun",
> > one waiting to remotely log into another machine, and another one giving
> > a shell on my own machine.)

> Notice that most of what you point out as the desirable qualifies as simple
> monitor tasks.

Almost isn't good enough.  Right now, the shell remotely logged in to "sun"
is active, and the shell on my own machine is semi-active - earlier today it
was *quite* active recompiling a kernel while this one was also logged in to
"sun" while I was reading my news (reading news while waiting for a compile
to finish is sort of like reading while sitting on the... well, you know).
If the compile stopped for some reason, I could switch my attention
relatively quickly to the other screen.

> And at that you are obviously aware of how much "horsepower"
> these tasks take up - you run a utilization monitor.

Yes, I am.  They take up a negligible amount of time.  The only monitoring
tasks are the clock, the mail monitor, and the CPU monitor.  The mail
monitor checks every 5 minutes, so it's not consuming much time.  On an idle
machine the CPU time graph is flat at 0% (i.e., <epsilon>%) - that's *with*
both of those monitoring tasks running.  The shells, when idling, don't take
up any CPU resources at all.  The resource that's really eaten up by all
this stuff is swap space (4.2BSD's profligacy with swap space has been much
discussed in net.unix-wizards, but that's another topic).

> I have no doubts that such systems will be the "wave of the future", but
> if I can't turn it off when I want my machines full attention on something
> I consider important, I'd rather not have it. [ Personal peeve ]

Definitely personal; I'd go batty on a single-tasking system no matter how
fast it was, unless it was *so* fast that I never had to wait for it to
complete any of the tasks (and even then I'd sorely miss having multiple
windows).

If your task is *so* CPU-bound and *so* time-critical that the machine can't
do *anything* else while it's running, there are a number of possibilities:

1) somehow putting the task outside the reach of the scheduler and giving it
direct access to all the resources it needs (i.e. running it either as a
specialized part of the OS kernel or as a peer of the OS kernel)

2) dedicating a special processor to the task (Masscomp uses this approach
for high-speed data acquisition; I think they claim the ability to sample at
1MhZ which is difficult, at best, with *any* general-purpose processor - a 1
MIP processor would have to execute one instruction per sample...)

Otherwise, as long as your OS permits reasonably direct access to the
resources a task needs, and has a scheduler that requires minimum overhead
if all the "time-sharing" tasks are blocked or running at a worse priority
than your real-time task (and doesn't try and time-slice the real-time
tasks), a multi-tasking OS is probably good enough.

	Guy Harris

steve@kontron.UUCP (Steve McIntosh) (07/01/85)

>> If I can't put my machines whole attention on a task when I want to...
>> [personal peeve]
 
> Definitely personal; I'd go batty on a single-tasking system no matter how
> fast it was, unless it was *so* fast that I never had to wait for it to
> complete any of the tasks (and even then I'd sorely miss having multiple
> windows).
> 	Guy Harris
 
I use my machine mostly for telecommunications, but what I really like to
do is crunch pixels. When doing image enhancement or analysis, even a
small overhead can drastically extend how long it takes to process a
frame.

(This is what I do for myself, at home, on a Commodore 64 with a 12.5
mhz 68000 attached processor board (Dtack grounded) - what I do at work
is completely different.)

If/when the Atari ST and/or Amiga hit the market, I plan to choose one
or the other as my new home system - and then find an implementation of
OS-9 to put on it. (Yes, OS-9 is multitasking)

My home system is the only one I can count on having access to. In this
business you never know what machine you are going to be using from
month to month. 

I have to choose very carefully what I want at home, as the computer
budget competes for money with the beer budget. Do you have a "home"
system? If you don't what would you (really) be able to buy and what
software would it run?

-Steve McIntosh, Kontron Electronics, Irvine CA
[My opinions are my own, and fairly unpopular..]

     {{ Don't give robots artificial intelligence - give 
        them the real thing - then run for the hills.}}

guy@sun.uucp (Guy Harris) (07/08/85)

> > ... I'd go batty on a single-tasking system no matter how
> > fast it was, unless it was *so* fast that I never had to wait for it to
> > complete any of the tasks (and even then I'd sorely miss having multiple
> > windows).
>
> I have to choose very carefully what I want at home, as the computer
> budget competes for money with the beer budget. Do you have a "home"
> system? If you don't what would you (really) be able to buy and what
> software would it run?

I presume this question was directed at me; for the record:

No, I don't have a home system; I have no use for one.  Since I do have no
use for one, the question of what I'd really be able to buy and what
software it'd run is irrelevant.  At work, however, I'm quite glad I have a
machine which supports multiple tasks.  The original poster seemed to think
that multi-tasking in a workstation was of little use; I was pointing out
that this is false.  Multi-tasking will increase the cost of your
workstation (if not in hardware, then in software complexity).  It's not
worth the money to some people.  It is worth the money to others.  A general
statement that it's unnecessary is silly.

	Guy Harris