On 2003.11.15, at 08:39  AM, E. Seth Miller wrote:

> John-
> 	Thanks for the information.  I hadn't realized that the buggy
> LC040s were fine as long as they weren't doing floating-point 
> emulation.
> ...

I used to think I knew more than I actually did about the problem,
so take this with a grain of salt. But the way I remember it, there
was a bug in the way the CPUs in the problem mask sets handled
the FPU emulation exceptions. It was one of those address
sensitive bugs, as well, so the exception stack frame would be
properly set up unless the exception occurred in address ranges
matching certain patterns.

Apple really didn't actually avoid the problem. SANE is subroutine,
so the emulation exception _should_ never occur. But you know
how that goes. Software that doesn't use the right way of checking
the CPU, or software where the programmer simply forgot/didn't
know and slipped in an FPU instruction, just boofs in odd places.
It seems to depend somewhat on where the object gets loaded
and somewhat on where the stack gets allocated. (And that
includes some ostensibly Apple software.)

They had to offer free replacement CPUs for a while, but there
were (of course) a lot of machines that the owners either did not
know about the replacement, or did not bother, including the
Performa 630/TV I inherited.

Fortunately, the bad exception frame causes a bad-exception-
frame exception (at least as far as I have noticed). The double
exception is basically irrecoverable, but at least it boofs instead
of silently corrupting data. That is, _I_ haven't seen any data
corruption occurring. ;*/

But I still will use a slower '030 box for production compiling
for the older Mac systems, just to be safe.

I suppose I really should back up those drives I've been putting
off, and give Klos's new images a shot. But I have some shift-JIS
ctype libraries I've got to write first. >8-)