earle@jplopto.uucp (Greg Earle) (10/29/87)
The new EDN shows a Motorola VME board with a 20 MHz 68030 and 68882 FPU on it. It has 256Kb on board and I believe 2 serial ports and PROM debugger. Now that it's no longer vaporware, can someone (preferably from Motorola) comment on the differences between the 68030 and 020, and also the 882 vs. 881? I know the 68030 has some MMU circuitry on chip, but I heard this can be disabled. My initial thoughts were, `A Sun-3/60 uses a 20 MHz 68020, I wonder what it would take to drop a 68030 in there at the same clock speed to turbo-ize it.' Since Sun handles their own memory management, that part of the 68030 would have to be turned off/disabled, but I'm sure there are many other factors and/or incompatibilities (I don't even know how close the pinouts are), so I'd like a Shell Answer Grape to enlighten me about them. Thanx, Greg Earle earle@jplopto.JPL.NASA.GOV S(*CENSORED*)t earle%jplopto@jpl-elroy.ARPA [aka:] Rockwell International earle%jplopto@elroy.JPL.NASA.GOV Seal Beach, CA ...!cit-vax!elroy!smeagol!jplopto!earle
motsea@amc.UUCP (Motorola Seattle ) (10/30/87)
In article <4733@elroy.Jpl.Nasa.Gov> earle@jplopto.JPL.NASA.GOV (Greg Earle) writes: >The new EDN shows a Motorola VME board with a 20 MHz 68030 and 68882 FPU on >it. It has 256Kb on board and I believe 2 serial ports and PROM debugger. >Now that it's no longer vaporware, can someone (preferably from Motorola) >comment on the differences between the 68030 and 020, and also the 882 vs. 881? The 68030 incorporates a subset of the 68851 PMMU onchip, as well as an added logical data cache, on-chip Harvard architecture [independent busses for both instructions and data], and modified bus interface logic to allow 2 clock synchronous access, burst filling of caches using nibble mode rams, as well as the 3clock async bus interface. It is not a drop in replacement for the 020. The 68882 *** IS *** a drop in replacement for the 68881. By reconfiguring the internal architecture [primarily in floating point register access], it is able to achieve typically 50% better performance than an 881 [all other factors being equal], and can go 2x with minor code mods... > >Thanx, > > Greg Earle earle@jplopto.JPL.NASA.GOV > S(*CENSORED*)t earle%jplopto@jpl-elroy.ARPA [aka:] > Rockwell International earle%jplopto@elroy.JPL.NASA.GOV > Seal Beach, CA ...!cit-vax!elroy!smeagol!jplopto!earle ...mark konopacky fae motorola seattle email: ...uw-beaver!tikal!motsea!mark [I am fortunate to use Applied Microsystems' node for news...] << Standard Disclaimer >>
allen@ccicpg.UUCP (Nebraska Ned) (11/02/87)
>The 68882 *** IS *** a drop in replacement for the 68881.
This may be true for hardware, but not software. The internal state frames
for the idle and busy states on the '882 are larger than that of the '881.
The operating software can tell the difference by the format word in
the state frame.
Allenheiby@mcdchg.UUCP (11/04/87)
Allen H. Brumm (allen@ccicpg.UUCP) writes: > >The 68882 *** IS *** a drop in replacement for the 68881. > > This may be true for hardware, but not software. The internal state frames > for the idle and busy states on the '882 are larger than that of the '881. 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. If you are mucking around with the internal state frames of a chip in a way that violates the documented ways of using it, then you get what you deserve. In the same sense, the stack frames generated by (for example) a BUS ERROR with a MC68030 will differ from those generated by the same condition with a MC68020. Obey the rules and you won't get burned. The whole point is that the '030 is USER LEVEL OBJECT CODE COMPATIBLE with the '020. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "I know engineers. They love to change things." McCoy
root@cca.ucsf.edu (Computer Center) (11/06/87)
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.
: If you are mucking around with the internal state frames of a chip in
: a way that violates the documented ways of using it, then you get what
: you deserve. In the same sense, the stack frames generated by (for
: example) a BUS ERROR with a MC68030 will differ from those generated by
: the same condition with a MC68020. Obey the rules and you won't get burned.
: The whole point is that the '030 is USER LEVEL OBJECT CODE COMPATIBLE
: with the '020.
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 think this stretches the terminology in an unjustified way.
I take it that the chips are "command level" and "computationally"
compatible in their architecture and physically and electrically
compatible on the hardware side, but their exception handling and
task switching behaviour is different.
"Drop-in replacement" implies that if one of the old chips fails
in a piece of equipment I can use the new one as a replacement
without other changes.
Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca
(The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos)
If he says it's "user friendly" watch out; he's a con artist.
#include <disclaimer.std>gnu@hoptoad.uucp (John Gilmore) (11/07/87)
> The 68882 *** IS *** a drop in replacement for the 68881. Allen H. Brumm (allen@ccicpg.UUCP) writes: > This may be true for hardware, but not software. The internal state frames > for the idle and busy states on the '882 are larger than that of the '881. heiby@mcdchg.UUCP (Ron Heiby) wrote: > If you are mucking around with the internal state frames of a chip in > a way that violates the documented ways of using it, then you get what > you deserve. 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. 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. I built a set of Sun-1 boot PROMs that would boot either a 68000 or a 68010, by causing a trap and seeing how much the stack pointer moved, and adjusting the other places that needed to know. But it's likely that those PROMs would not be able to boot a 68020...or 68030. > Obey the rules and you won't get burned. For a manufacturer, this should read "obey the rules and you'll only have to do a minor software update". That's certainly better than having to rewrite all your user programs to go from 8086 to 80286, but it's not the whole story. -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania
schmitz@ARM.RI.CMU.EDU (Donald Schmitz) (11/09/87)
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.
heiby@mcdchg.UUCP (Ron Heiby) (11/10/87)
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