Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!PT.CS.CMU.EDU!ARM.RI.CMU.EDU!schmitz
From: schmitz@ARM.RI.CMU.EDU (Donald Schmitz)
Newsgroups: comp.sys.m68k
Subject: Re: MC68030 & MC68882 now out and available; comparisons with MC68020?
Message-ID: <330@PT.CS.CMU.EDU>
Date: Mon, 9-Nov-87 13:28:07 EST
Article-I.D.: PT.330
Posted: Mon Nov  9 13:28:07 1987
Date-Received: Wed, 11-Nov-87 06:39:27 EST
References: <4733@elroy.Jpl.Nasa.Gov> <542@amc.UUCP> <3570@ccicpg.UUCP> <2274@mcdchg.UUCP> <3297@hoptoad.uucp>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 55

It seems there is some misunderstanding in this dicussion between exception
stack frames and coprocessor state frames.  The coprocessor state frame
contains the internal state of the chip (micro pc, internal registers, etc.)
It is a variable size frame that contains no externally useful
information.  In the '881, it varies between 4 and 184 bytes.  The first 4
bytes of this frame contain the coprocessor verison number, and the _number
of bytes_ in the frame, not just a random identifier.  The fsave and
frestore functions push and pop them either from a stack or a specified
memory space.  This frame must be stored when doing a context switch, or
otherwise changing state via an interrupt or exception, IF the new
instruction stream will use the coprocessor.  Otherwise, an coprocessor
instruction can be fetched before the currently executing instruction 
terminates (coprocessors are loosely coupled to the CPU).  The size of the
state frame is determined by the state of the coprocessor when the fsave is
executed.

Exception frames are less regular, and are generated by the host CPU on a
variety of error conditions, including a coprocessor signalled floating
point error.  These frames contain the CPU state during an exception, and
are somewhat kludgy in the '020, apprarently to provide some degree of
backward compatibility to the '010. These frames are automatically saved on
the stack by the CPU when an exception is processed.  Upgrading to an '882
should have no effect on these exception frames.

>The point is that a Sun or Levco customer can't take a 68882 and 
>plug it in where the 68881 goes, since the operating system software
>provided by the manufacturers does not know to allocate that much space
>for the stack frame.  No "mucking around" is required, simple things
>like the space allocation for each process's floating point state will
>kill you.  Users end up having to wait for the manufacturer
>to update the software and/or firmware.

The coprocessor save mechanism must already support a variable sized state
frame.  If a little extra space was allocated for the '881, it should
support the '882.  I'd guess Motorola let manufacturers know well before the
rest of us that the new part may take more space, and about how much, so
this should have been a reasonable thing to do (unless they want to make big
bucks selling the upgrade software, since the chip is a low profit item).  I
dont know how SUN or other real OS's handles the gory details of context
swapping, but the code I wrote saves it in a stack maintained for each
process, this stack is also the interrupt stack, so making it a little
oversize is no big deal.  None of the data in the saved frame is useful to
external code, so its exact format should not matter (Motorola explicity
says this in the '881 manual).

>I used to write that kind of code for Sun and it's easy to set it up
>*if you know the size of each stack frame*.  Unfortunately, the stack
>frame format field is just 4 bits, assigned at random, so there's no
>way a program can tell the size of a stack frame that wasn't designed
>yet when the program was written.

See above comments.  The coprocessor state frame concept is much more
regular than the CPU exception frames, and is designed to support variable
size frames.  Good software, at least the kind you pay for, should handle 
this easily.