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: gnu@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.