[net.micro.68k] 68020 vs. 32032, pros and cons

gnu@sun.uucp (John Gilmore) (06/12/84)

> National seems to have decided to do simpler components optimized to what they
> consider to be the average use, rather than fancy parts that can be adjusted
> to optimize your particular use.  In exchange, national was able to produce
> their parts, while motorola is still dreaming.
Motorola's first parts were simple too, but they've been improving them
over the years.  (Over half of the 68000 microcode was rewritten for the
68010.  Probably all of it is being done again for the 68020.)

Nobody can dispute that the 16032's instruction set is seriously
orthogonal, while the 68000 series only makes a half-hearted attempt.
Nick Tredennick, who wrote the 68000 microcode, claims it's mostly his
fault, because he couldn't make it all fit on the chip.

The big Motorola win for me is performance.  Motorola has shown that
they can produce full-speed chips; we had a 16MHz 68000 sample close to
two years ago, and many people run 12.5MHz production.  People from
National keep telling me that the 10MHz part is real, but somehow their
customers keep mentioning 6MHz.  Does a 6MHz 32032 outrun a 12.5MHz 68000?

Also, I got the impression that the 32032 is not even close to twice as
fast as the 16032 -- my correspondent seemed to think it ran roughly
the same speed, since they didn't increase the internal processing
speed even though they doubled the memory bandwidth.  (68000-era
processors and bus interfaces run at almost exactly the same speed, which
means that just widening the bus would not speed them up much.)  Motorola
is speeding up the processor clock rate, the internal algorithms, the
bus width, and the bus cycle time in clocks, while reducing the demand
for bus accesses -- all by significant factors.  I'll be glad to hear
differently if National really did improve the guts of the 16032 to
make the 32032 -- can anyone confirm or deny?

> You will pay for that extra bit of performance through the nose though.
OK, tell me the cost, don't just wave your hands.

PS:  If you want to build a co-processor of your own, don't try to hang
it on a 32032; the CPU decodes the co-processor instructions, so you'll
need a new CPU chip too, unless your co-processor instructions look a
lot (well, OK, exactly) like their float box's.  Motorola got it right.

PPS:  I'm pleased to see that unlike Intel, National is aggressively
encouraging people to hook up their float chip to 68000 systems.  Digital
Acoustics is having great fun with them; they claim a 12.5MHz 68000 can
keep two 16081's busy at once for serious numeric work.

phil@amd70.UUCP (Phil Ngai) (06/13/84)

I had read (in some National propaganda, I think) that all they did
for the 32032 was hack the bus interface unit. They also admitted
the 16032 was basically compute bound and the 32 bit bus only gained
25% more performance. The marketing department loves it, however.
As long as they can say 32 bit bus, who cares if it's faster?

I have no particular axe to grind with National's micros. I think
their instruction set is nice and their MMU one of the best available
(although that isn't saying much).

It's a shame that Motorola thinks the way to high performance is
to crank up the clock rate. It's really expensive to provide the
kind of memory needed by a 16 MHz processor.

	trying not to be biased,
-- 
Phil Ngai (408) 982-6825 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil

nather@utastro.UUCP (Ed Nather) (06/13/84)

[]
    >It's a shame that Motorola thinks the way to high performance is
    >to crank up the clock rate. It's really expensive to provide the
    >kind of memory needed by a 16 MHz processor.
    >
    >	trying not to be biased,
    >-- 
    >Phil Ngai

This makes no sense to me.  Traditionally the cpu operations have always
been faster than memory operations, since the same technology applied to
either operation favors the simpler.  We've learned how to make registers
really fast, and cpu operations parallel and individually simple because
we can afford to dissipate a lot of power to crunch one word -- but we
can't afford the same power in a semiconductor memory system on a per-word
basis.

It seems to me the best way to make a computer go twice as fast is to double
the clock speed.  If the memory cost rises more than a factor of 2 we then
lose ground on all applications where the cost vs time tradeoff is linear --
not all applications by any means.  Now try to get the memory to go faster.
Trying to gain a factor of two by changing only the architecture, and keeping
the clock speed the same, is terribly difficult if not impossible.  I tried
it once, and lost.

-- 

                                 Ed Nather
                                 {allegra,ihnp4}!{ut-sally,noao}!utastro!nather
                                 Astronomy Dept., U. of Texas, Austin

davecl@mako.UUCP (06/15/84)

The following are my impressions based on the instruction set
manuals, instruction timings and comments from other people.

As far as the bus interface is concerned, the 16032 (which is supposedly
now being renamed to the 32016 since the TI announcement) corresponds
most closely to the 68008 or 8088.  The 32032 corresponds to the
68000 or 8086.  In a sense everything was designed for the 32032 all along;
the 16032 came out earlier because that was a physical package that could
be done sooner.

The performance numbers that I've heard is that the 32032 should represent
a 25-40% improvement over the 16032, depending on the application.

To get a National part with the maturity of development represented by
the 68020, you'll have to wait for a later part (like the 32132?).

dgc

phil@amd70.UUCP (Phil Ngai) (06/25/84)

When I said "it's a shame National thinks the way to speed up a computer
is to increase the clock", I expected people to think of pipelining.

I think benchmarks which show how well a particular device performs
at 16 MHz with no wait state memory are somewhat misleading in that
such memory is quite expensive and either the system will be more
expensive or the system won't perform as well in reality.

I submit the bus interface of the 286 as an example of a well thought out,
efficient memory interface. But I've already gotten on my soapbox about
this so I'll just go quietly.

-- 
Phil Ngai (408) 982-6825 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil

simon@dice.UUCP (Simon Kenyon) (07/12/84)

Forgive me for asking, but am I not correct in thinking
that these super whizzo ultra fast 68ks are just that:
to wit 68000s, and not 68010s.
For if that is the case then they are of very little use
to anyone, (virtual memory and all that).
32016s and 32032s (as they are now called, I'll always
call a 16k a 16k, it is too late to change now) are the
way to go, though it is a pity about the string instructions
using general registers, and the move multiple instruction,
and the fact that just about no instruction sets the b****y
condition codes.

Anyone out there got genix? We have and would like to talk,
exchange firside stories etc.
(in a whisper) anyone got a 16k Fortran compiler? Even better
if it ran under genix!
--
Simon Kenyon. [funny little cute message! ... jeez]
{ ...vax135!ukc!edcaad or ...decvax!mcvax } !dice!simon
55 51' 49" Lat, 3 31' 46" Long (i.e. this side of the pond)

beaucham@uiucuxc.UUCP (07/12/84)

#R:dice:-12000:uiucuxc:18900006:000:789
uiucuxc!beaucham    Jul 12 12:53:00 1984

National is evidentally running Genix on their system, and LMC (Logical
Microcomputer in Chicago) says they will be supplying Genix with their
system with a month or two.  LMC is presently supplying the Unity port
(by HCR) which is quite slow, and they are expecting a x2 speed up with
Genix.  HOWEVER, Unity does include F77 and Genix does not. {my experience
with Unity F77 is that it compiles slowly and executes slowly on short
programs (x10 VAX780 no fpa) but with long fltng pt executions it does
much better (106 sec LMC vs 37 sec VAX on one benchmark).}  LMC says it
will supply F77 as an option with Genix, but i dont know whose version 
it will be.
  
    please let me know if you hear anything.
  
         Jim Beauchamp  {ucbvax,pur-ee,allegra,ihnp4}!uiucdcs!uiucuxc!beaucham