Re: Software FPU emulation in linux kernel

[Brad Boyer <flar@allandria.com>]

On Tue, Mar 04, 2025 at 06:24:30AM +0100, Thorsten Otto wrote:
> On Montag, 3. M?rz 2025 23:10:12 CET Brad Boyer wrote:
> > Well, most programs that use FPU instructions aren't going to use anything
> > beyond the basics.
> 
> Thats true. But if they do, wouldn't it be better to just abort the
> program so the user will notice it, rather than continuing with
> totally bogus values? Currently, uprint will just use the kernels
> printk. I guess that will just end up in the syslog for most cases,
> and not even seen by the user.

Yes, it should cause an unimplemented instruction trap or something like
that. I was just pointing out that there aren't likely to be a lot of
programs anyone is using on an m68k Linux system that would notice.

> > In practice, no. There's a lot of other issues as well. I seem to
> > recall that it only supports the 020/030 and not the versions of
> > the 040/060 without FPU.
> 
> Thats mostly a matter how it is integrated in the system. That will obviously 
> be totally different in my case.

True, but it is further evidence that it doesn't actually get used.

> > Most existing 68LC040 chips also have the bug that causes missed
> > page faults after software-emulated instructions as well
> 
> Oh, i didn't know that. But handling pagefaults is another thing. But
> freemint does not manage virtual memory, so that should not be a
> problem here.

If you're curious, it's #10 in this list:

https://www.nxp.com/docs/en/errata/MC68040DE_D.txt

A lack of virtual memory should prevent it, as you pointed out.
Interestingly, it's not actually specific to FPU emulation even
though it was normally known for causing issues with FPU. Apple
had a generic workaround in their OS for everything other than
the floating point exceptions (they use a different frame type).

	Brad Boyer
	flar@allandria.com