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@xxxxxxxxxxxxx
