gnu@sun.uucp (John Gilmore) (07/12/84)
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.
henry@utzoo.UUCP (Henry Spencer) (07/15/84)
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!henrymats@dual.UUCP (Mats Wichmann) (07/16/84)
Actually, official sampling of the 68020 is not due until 4th quarter
of this year. To get a chip anytime soon, you have to be on an `advance list',
which means either a VERY long-standing relationship with Motorola, or orders
in the megabuck range.
Mats Wichmann
Dual Systems Corp.
...{ucbvax,amd,ihnp4,cbosgd,decwrl,fortune}!dual!matsgnu@sun.uucp (John Gilmore) (07/17/84)
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.
kds@intelca.UUCP (Ken Shoemaker) (07/17/84)
> ....... 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.
mwm@ea.UUCP (07/19/84)
#R:sun:-154300:ea:7400004:000:812
ea!mwm Jul 18 16:29:00 1984
/***** ea:net.micro.68k / utzoo!henry / 2:02 pm Jul 15, 1984 */
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
/* ---------- */
That's not a wart, that's a *feature*. They call it "instruction
continuation," as opposed to the more conventional "instruction restart."
They designed it that way.
It's supposed to be a performance enhancement - you don't have to roll the
instruction back [for things like MOVE.W (A0)+,(A1)+], and you don't have
to redo the rolled-back part of the instruction when you continue the
faulted process. Whether or not it works in practice, or the pain of
dealing with it is worth the gain, I don't know
<mikedavid@bragvax.UUCP (David DiGiacomo) (07/19/84)
>>> ... 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.... >>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 ... Ken, I love it when you spout off about things you know TOO much about! In this case, you seem to be reacting to the keyword "general", which should probably be read as "useful". The 8086/8087 interface is a wart because: 1) It is not documented well enough to allow construction of additional coprocessors by third parties. 2) Even if it was documented, it is not suited to MSI coprocessor implementation, due to its complexity and critical timing. Anyway, how do YOU define "coprocessor"? At Intel 3 (8089, 82586, 82730) out of 5 (+ 8087, 80287) "coprocessors" are what I would call "channels", since they don't share the instruction stream of the CPU.
phil@amd.UUCP (Phil Ngai) (07/21/84)
Gee Dave, do you think you should have prefaced your comments with a
"As a former Intel employee..."?
--
Just another valley guy
Phil Ngai (408) 982-6554
UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!phil
ARPAnet: amd!phil@decwrl.ARPA