Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!oakhill!motaus!phil
From: phil@motaus.UUCP (Phil Brownfield)
Newsgroups: comp.sys.m68k
Subject: Re: 68040 not object code compatible?
Summary: architecture vs. implementation
Message-ID: <2446@motaus.UUCP>
Date: 1 Mar 90 04:47:39 GMT
References: <300003@hpclkms.HP.COM> <9816@cbmvax.commodore.com> <4999@scolex.sco.COM>
Reply-To: phil@motaus.UUCP (Phil Brownfield)
Organization: Motorola Semiconductor, Austin, Texas
Lines: 43

How to view 68000 family user mode upward object code compatibility
depends on whether one sees a difference between instruction set
*architecture* and instruction set *implementation*.  With an
MC68030/MC68882 chipset as the CPU, the implementation of all floating
point operations is done in hardware (read "microcode" if you prefer).
In the MC68040, the implementation of the simple floating point
operations (e.g. FADD, FMUL) is done in hardware, while implementation
of the more complex ops (e.g. FSIN, FMOD) is done by software in the
F-line emulation exception handler executing in supervisor mode.  In
either the MC68030/MC68882 chipset or the MC68040/exception handler
combination, the underlying implementation is invisible to a user mode
programmer.  The instruction set architecture available to user mode
programmers of either implementation is the same.

If this view seems of doubtful usefulness, check out how most current
RISC chipsets implement the operations required by the IEEE 754
floating point standard, to pick one of several other examples.

MOVE from SR for user mode programs can be emulated fairly easily
in the privilege violation exception handler, if a system implementer
feels the need and a given chip doesn't support the operation.  I
guess it could be debated whether CALLM/RTM were retroactively declared
not a part of the 68000 family instruction set *architecture*; or
whether they were just a feature of the MC68020 MPU and MC68851 PMMU
chipset *implementation*.

>>I know, I know, the response to that is going to be "we didn't mean to
>>include the coprocessor". *sigh*
>
>No, the response is going to be:  "but you wanted it fast, didn't you?"

More or less this is right.  But to clarify:  by bringing the FPU onto
the 040 the speed of simple FP operations was improved enough that
sequences of the 040's simple operations can perform the complex FP
operations faster than the MC68882's microcoded implementation.  And
if you can eliminate silicon without a performance penalty generally
you win, because either the chip becomes more buildable or you can
apply the silicon to other features.

--
Phil Brownfield, Motorola Semiconductor
{cs.utexas.edu!oakhill, mcdchg}!motaus!phil
Speaking for myself, not my employer