Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!hplabs!motsj1!mcdchg!heiby
From: heiby@mcdchg.UUCP (Ron Heiby)
Newsgroups: comp.sys.m68k
Subject: Re: MC68030 & MC68882 now out and available; comparisons with MC68020?
Message-ID: <2368@mcdchg.UUCP>
Date: Tue, 10-Nov-87 15:17:46 EST
Article-I.D.: mcdchg.2368
Posted: Tue Nov 10 15:17:46 1987
Date-Received: Fri, 13-Nov-87 21:32:46 EST
References: <4733@elroy.Jpl.Nasa.Gov> <542@amc.UUCP> <3570@ccicpg.UUCP> <2274@mcdchg.UUCP> <1068@ucsfcca.ucsf.edu>
Reply-To: heiby@mcdchg.UUCP (Ron Heiby)
Organization: Motorola Microcomputer, Schaumburg, IL
Lines: 61

Computer Center (root@cca.ucsf.edu) writes:
> In article <2274@mcdchg.UUCP>, heiby@mcdchg.UUCP (Ron Heiby) writes:
> : 
> : I think that the intention of the statement was that it is a drop-in
> : replacement in the hardware sense *and* in the USER LEVEL software sense.
> 
> Ron Heiby seems to suggest that the OS support of these processors may
> not be compatible but that the new one is still a "drop-in replacement".

I apologize if I misled anyone.  I am in the "systems" side of the business
and, as I have not yet seen an '882 from my comrades in the semiconductor
side, I "only know what I read in the papers".

> I take it that the chips are "command level" and "computationally"
> compatible in their architecture and physically and electrically
> compatible on the hardware side,

I know that the above is true, based on information I have received on
the 68882 chip.

> but their exception handling and task switching behaviour is different.

I don't know that this is the case.  I believe that it is not.  What I
meant to say in my original article was that details such as length of
the state information or placement of specific information within that
"state frame" *may* have changed.

Because of this misunderstanding, I asked one of my semiconductor friends
about the chip and he gave me a copy of the "Motorola Semiconductor
Technical Data" sheet entitled "HCMOS Enhanced Floating-Point Coprocessor;
MC68882 Technical summary" with number "BR509/D".  It begins with:
	"The MC68882 enhanced floating-point coprocessor is a full
	implementation of the IEEE Standard for Binary Floating-Point
	Arithmetic (754) for use with the Motorola M68000 Family of
	microprocessors.  It is a pin and software compatible upgrade
	of the MC68881, with an optimized MPU interface that provides
	over 1.5 times the performance of the MC68881.  It is implemented
	using VLSI technology to give systems designers the highest
	possible functionality in a physically small device."

Later (page 7) of the same data sheet talks about FSAVE and FRESTORE,
which seems to be of great concern to some people in this group.  After
explaining what the two instructions are good for, the following is
stated:
			"NOTE
	While the MC68882 is instruction set compatible with the
	MC68881, the idle and busy state frames are both 32 bytes
	larger on the MC68882 than on the MC68881.  A unique format
	word is generated by the MC68882 so that system software
	can detect this difference."

(I think they meant to say "each 32 bytes larger" rather than "both 32
bytes larger", but you get the idea.)

So, it appears that if you have allocated *exactly* enough space for
the MC68881 busy state frame, then you are 32 bytes short if you plop
in an MC68882.  I hope this clears things up sufficiently.  Sorry for
the confusion.  Let me know if I can help further.
-- 
Ron Heiby, heiby@mcdchg.UUCP	Moderator: comp.newprod & comp.unix
"I know engineers.  They love to change things."  McCoy