Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site trwspp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!floyd!
harpo!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!trwrb!trwspp!aoki
From: a...@trwspp.UUCP
Newsgroups: net.micro,net.micro.68k,net.arch
Subject: 68020 vs. 32032
Message-ID: <452@trwspp.UUCP>
Date: Sat, 2-Jun-84 21:34:31 EDT
Article-I.D.: trwspp.452
Posted: Sat Jun 2 21:34:31 1984
Date-Received: Wed, 6-Jun-84 04:19:50 EDT
Organization: T R W, Redondo Beach, CA
Lines: 16
[munch .unch ..nch ...ch ....h .....]
I quite sure this has been hacked around before, but here
goes anyway.
68020 vs. 32032 which is better to base your system around?
(assuming the 32032 is available)
::::: Dean :::::
UUCP: { ucbvax | decvax } !trwrb!trwspp!aoki
ARPA: !trwrb!trwspp!aoki@BERKELEY
USPS: T R W Defense Systems Group
One Space Park MS: 119-2142F
Redondo Beach, CA 90278
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 Fluke 1/4/84; site fluke.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!vax135!cornell!uw-beaver!microsoft!
fluke!kurt
From: k...@fluke.UUCP (Kurt Guntheroth)
Newsgroups: net.micro,net.micro.68k,net.arch
Subject: Re: 68020 vs. 32032
Message-ID: <1048@vax2.fluke.UUCP>
Date: Wed, 6-Jun-84 12:27:49 EDT
Article-I.D.: vax2.1048
Posted: Wed Jun 6 12:27:49 1984
Date-Received: Sat, 9-Jun-84 08:05:18 EDT
References: <452@trwspp.UUCP>
Organization: John Fluke Mfg. Co., Everett, WA
Lines: 23
go ahead bug, make my day.
I like the 32032. Simpler chip (less transistors == more reliable (?), MUCH
more orthogonal instruction set (better -> faster compilers, faster, more
compact object code), 32032 available now (6mhz version), along with fpu and
mmu.
Now, when the 68020, motorola fpu and advanced mmu become available, the
fanciest system you could build with motorola parts will probably outperform
the fanciest system you can build with (currently proposed) national parts.
You will pay for that extra bit of performance through the nose though.
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.
No connection to mot or nsc, always my own opinions
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro,net.micro.68k,net.arch
Subject: Re: 68020 vs. 32032
Message-ID: <3948@utzoo.UUCP>
Date: Fri, 8-Jun-84 17:16:57 EDT
Article-I.D.: utzoo.3948
Posted: Fri Jun 8 17:16:57 1984
Date-Received: Fri, 8-Jun-84 17:16:57 EDT
References: <452@trwspp.UUCP>, <7966@watmath.UUCP>
Organization: U of Toronto Zoology
Lines: 8
I believe Motorola has said that the support chips for the 68020 will
be available "several months after the 68020". In other words, just
this side of never.
And as Jan Gray reported, 32032's are available *now*.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!linus!vaxine!wjh12!genrad!decvax!decwrl!sun!gnu
From: g...@sun.uucp (John Gilmore)
Newsgroups: net.micro,net.micro.68k,net.arch
Subject: Re: 68020 vs. 32032, pros and cons
Message-ID: <1254@sun.uucp>
Date: Tue, 12-Jun-84 04:00:28 EDT
Article-I.D.: sun.1254
Posted: Tue Jun 12 04:00:28 1984
Date-Received: Thu, 14-Jun-84 06:37:07 EDT
References: <452@trwspp.UUCP> <1048@vax2.fluke.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 43
> 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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!gnu
From: g...@sun.uucp (John Gilmore)
Newsgroups: net.micro.68k, net.micro.16k
Subject: 68020 production samples announced
Message-ID: <1543@sun.uucp>
Date: Thu, 12-Jul-84 09:40:37 EDT
Article-I.D.: sun.1543
Posted: Thu Jul 12 09:40:37 1984
Date-Received: Sat, 14-Jul-84 02:18:35 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 36
According to Electronics, July 12, page 46 and pg 130:
Motorola is offering 68020 samples that run at 12.5MHz and cost $487.
Initial production of 16.67MHz parts is expected in early 1985, with
volume production in the 2nd quarter. At 16.67MHz, it runs 68000 code
at 2.5 MIPS continuously, or up to 8 MIPS in bursts, while drawing only
1W. This is 3.25 times as fast as the 68000 and much faster than a Vax
780. (They delayed it by 6 months to incorporate more high-speed CMOS,
reducing the power from 2.5W and upgrading the speed from 1.5 MIPS.)
The address and data buses are both 32 bits (it comes in a 114-pin
pin-grid array) and it deals on-the-fly with misaligned storage
references as well as 8-bit, 16-bit, and 32-bit memories and
peripherals. On each access, the peripheral tells it how much data was
accepted or provided; if there is more, the 68020 will run further
cycles at higher addresses until it's all accepted. The bus design
is very elegant and easy to interface with.
There is a 68020 User's Manual which, like the 68000 Fourth Edition
manual, is published by Prentice-Hall. The instruction timings are out
of this world -- the charts are 20 pages, plus 8 pages of text which
explains with colored examples that because of the pipelining you can't
rely on the charts. It has a 256-byte cache on-chip for instructions,
incurring no prefetch delays for instructions which are in the cache,
and overlapping their execution with bus cycles generated by previous
or following instructions.
The instruction set is a superset of the 68010, including full 32-bit
displacements everywhere, scaled indexing, and memory indirect
addressing modes. There are 32x32->32 multiply and divide as well as
the traditional 32x32->64 variants. Rational bit (and bit-field)
addressing instructions are included. They threw in a few goodies for
ring-style protection systems and separate interrupt and supervisor
stacks, as well as a truly general coprocessor interface, unlike the
warts put out by Intel and National that hook up their float chip
and nothing else. All in all, not a bad deal for $500.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: 68020 production samples announced
Message-ID: <4089@utzoo.UUCP>
Date: Sat, 14-Jul-84 22:40:50 EDT
Article-I.D.: utzoo.4089
Posted: Sat Jul 14 22:40:50 1984
Date-Received: Sat, 14-Jul-84 22:40:50 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp>
Organization: U of Toronto Zoology
Lines: 21
If Motorola can really deliver working chips to that sort of spec,
this is indeed pretty impressive. (Emphasis on the word "working";
that means nothing serious on the bug list, guys!) (Just because
a semiconductor company sells a chip, doesn't mean it works. Often
the part will be "available" for some time before the bug lists get
down to the point where you can live with them.)
I do take exception to one comment of gnu's:
....... as well as a truly general coprocessor interface, unlike the
warts put out by Intel and National that hook up their float chip
and nothing else....
No argument about Intel... but National's slave-processor interface is
general enough that many people use the National floating-point chip on
non-National cpus like the 68000. And as far as warts go, has Motorola
fixed that awful botch of having to save microcode state when the cpu
gets a page fault?
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!gnu
From: g...@sun.uucp (John Gilmore)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: 68020 production samples announced
Message-ID: <1551@sun.uucp>
Date: Tue, 17-Jul-84 05:06:43 EDT
Article-I.D.: sun.1551
Posted: Tue Jul 17 05:06:43 1984
Date-Received: Wed, 18-Jul-84 06:28:58 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 48
Replies to Henry Spencer's comments on 68020 announcement:
If Motorola can really deliver working chips to that sort of spec,
this is indeed pretty impressive. (Emphasis on the word "working";
that means nothing serious on the bug list, guys!) (Just because
a semiconductor company sells a chip, doesn't mean it works. Often
the part will be "available" for some time before the bug lists get
down to the point where you can live with them.)
The 68020 has a bug list but we don't expect trouble from any of them,
as far as prototyping is concerned.
I do take exception to one comment of gnu's:
....... as well as a truly general coprocessor interface, unlike the
warts put out by Intel and National that hook up their float chip
and nothing else....
No argument about Intel... but National's slave-processor interface is
general enough that many people use the National floating-point chip on
non-National cpus like the 68000.
Uh...that's great if you want to drive a National float chip from somewhere
else, but suppose you want to build a graphics chip into the instruction
set of a 16032 (or whatever it's called)? The CPU knows exactly how to decode
each "co-processor" instruction, leaving precious little flexibility for
the co-processor designer. S/he can say what each instruction does,
but not what operands it takes.
And as far as warts go, has Motorola
fixed that awful botch of having to save microcode state when the cpu
gets a page fault?
There are many ways to resume after page faults; National chose one way
(also chosen by several manufacturers, including IBM) and Motorola
chose another (also chosen by other mfr's, including DG). Both
approaches have tradeoffs. Motorola's way optimizes performance for
the non-pagefault case, but costs a lot to take a fault. (Of course,
you have to wait for the disk arm to move anyway...) It also leaves
them with no restrictions on the instruction set in terms of when you
can write to memory. (The 16032 does not define what happens if you
use overlapping operands and take a page fault.) Note that both IBM
and National had to put "micro state" (eg intermediate counter values)
in general registers so their long-running string instructions would be
interruptable by page faults. The 68020 allows long-running CPU (and
co-processor) instructions to stop in mid-instruction and resume from
where they left off without complications in either the user program or
the page fault handler; the hardware handles it. It also allows the
opsys to simulate access to devices that don't exist, which IBM could
only do in VM because I/O access was all thru privileged instructions
rather than thru normal memory references.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site intelca.UUCP
Path: utzoo!linus!decvax!decwrl!sun!idi!intelca!kds
From: k...@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: 68020 production samples announced
Message-ID: <337@intelca.UUCP>
Date: Tue, 17-Jul-84 15:21:19 EDT
Article-I.D.: intelca.337
Posted: Tue Jul 17 15:21:19 1984
Date-Received: Wed, 18-Jul-84 07:00:15 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 22
> ....... as well as a truly general coprocessor interface, unlike the
> warts put out by Intel and National that hook up their float chip
> and nothing else....
>
>No argument about Intel... but National's slave-processor interface is
>general enough that many people use the National floating-point chip on
>non-National cpus like the 68000. And as far as warts go, has Motorola
I do SO love it when people spout off about things they seem to know little
about. I do suppose, however, that all of this really matters in how you
define "coprocessor." WRT the 8086, I'm kinda at a loss how it could
be made much more general in that all the processor supplies is the data
address. It is the coprocessor's responsibility to decode the instruction,
and run any required data cycles. Thus, anyone if they wanted to could make
a special function coprocessor to do anything they wanted to. That the
8087 connects specifically to the 8086 is a function that the processor
really does little work for the coprocessor, adding to the generality of
functionality possible in the coprocessor.
--
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
---the above views are personal. They may not represent those of Intel.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!
uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!decvax!decwrl!sun!gnu
From: g...@sun.uucp (John Gilmore)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Warty Intel co-processor interface
Message-ID: <1559@sun.uucp>
Date: Wed, 18-Jul-84 22:17:48 EDT
Article-I.D.: sun.1559
Posted: Wed Jul 18 22:17:48 1984
Date-Received: Tue, 24-Jul-84 03:41:58 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP>
<337@intelca.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 37
I do SO love it when people spout off about things they seem to know
little about. I do suppose, however, that all of this really matters
in how you define "coprocessor." WRT the 8086, ...
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
Actually I was talking about the 80286/80287. Intel refuses to
document the coprocessor interface (that should give you a clue right
there), so what follows is from guesses and experience rather than
specs.
The 286 decodes the floating point instructions and turns them into
references to I/O addresses 0xF8, 0xFA, and 0xFC. The 287 is wired
into the I/O decoding such that these addresses cause chip selects.
Typical instructions cause a read to 0xF8 (status register) to check
for busy, followed by writing the opcode to 0xF8. It then writes the
PC and EA to 0xFC, in case a fault occurs. The 286 then waits for the
287 to issue PEREQ; this indicates that an operand is wanted. The 286
fetches the operand and writes it to 0xFA, while asserting PEACK. (The
286 -- the CPU, not the float chip -- knows where the operand is, and
how many bytes it occupies.) When the 286 has transferred all the
operand bytes, it continues with the next instruction. The 286 and 287
microcode implements seven different variants of this protocol,
depending which float instruction is involved.
This is not a terrible way to attach a float chip. However, it does
not let you add arbitrary instructions to the instruction set, which is
the whole point of a general coprocessor interface. Nor does it let
you have two coprocessors even if the wired-in EA and operand size
decoding could be worked around -- so if you build a graphics
coprocessor you'll have to give up floating point. The 68020 provides
all these capabilities.
---the above views are personal. They may not represent those of Intel.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Warty Intel co-processor interface
Message-ID: <4134@utzoo.UUCP>
Date: Tue, 24-Jul-84 13:30:47 EDT
Article-I.D.: utzoo.4134
Posted: Tue Jul 24 13:30:47 1984
Date-Received: Tue, 24-Jul-84 13:30:47 EDT
References: <579@islenet.UUCP>, <120@dice.UUCP>, <1543@sun.uucp> <4089@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 28
John Gilmore comments, in part:
> This is not a terrible way to attach a float chip. However, it does
> not let you add arbitrary instructions to the instruction set, which is
> the whole point of a general coprocessor interface. Nor does it let
> you have two coprocessors even if the wired-in EA and operand size
> decoding could be worked around -- so if you build a graphics
> coprocessor you'll have to give up floating point. The 68020 provides
> all these capabilities.
Then Motorola may have goofed, and they'll find out the hard way.
What I was told, by a fellow who consulted for Intel, was that Intel
now regrets the "general coprocessor" interface on the 8087, and
thinks it a serious mistake. The trouble is that it adds a great deal
of complexity on the coprocessor chip for very little gain, compared to
the slave-processor approach of having the cpu do most of the work.
Intel's abandoning of the coprocessor interface for the 8028[67] tends
to confirm this report. It sounds like Motorola was taken in by Intel's
early coprocessor rhetoric, even as Intel was (internally) backpedalling
furiously.
There's no denying that the slave-processor approach makes it difficult
to add arbitrary customer-designed auxiliaries. But it would seem to be
the right way to add a floating-point chip, which is (I would speculate)
a much more important consideration from the manufacturer's viewpoint.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry