linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Thorsten Otto <admin@tho-otto.de>, linux-m68k@vger.kernel.org
Subject: Re: Software FPU emulation in linux kernel
Date: Tue, 4 Mar 2025 12:38:56 +1300	[thread overview]
Message-ID: <091d25fa-6a79-4685-a920-075611e79626@gmail.com> (raw)
In-Reply-To: <3374772.VqM8IeB0Os@earendil>

Thorsten,

On 4/03/25 05:22, Thorsten Otto wrote:
> Hi,
>
>
> i'm currently trying to port the software FPU emulation of linux-m68k to
> FreeMiNT, and got some questions about it.
>
>
> As seen in https://github.com/torvalds/linux/blob/
> 7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/m68k/kernel/vectors.c#L96 and
> https://github.com/torvalds/linux/blob/
> 7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/m68k/kernel/vectors.c#L119
>
> the FPSP for 040/060 are not installed when the software emulation is used.

That is correct - the FPSP and IFPSP packages are only meant to handle 
unimplemented instructions on the 040 and 060 processors, respectively. 
These packages were part of Motorola's developer support for 040/060, 
and are used unmodified (aside from kernel specific asm glue) by the 
Linux kernel.

The generic math emulation support was added much later, and is largely 
incomplete (many functions are just stubs, as you found out). The 
Kconfig help text for the M68KFPU_EMU option does note that BTW.

> However, almost all trigonometric functions are not implemented: https://
> github.com/torvalds/linux/blob/7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/
> m68k/math-emu/fp_trig.c#L21-L28
> What sense does it then make to use an emulation, when only basic instructions
> like fadd/fmul etc. are implemented? Programs are not even aborted when using
> one of those functions, uprint just prints an error message, and the functions
> just return with their input arguments as result instead of calculating the
> expected value.
As I recall it, the main purpose was to keep kernel and a few important 
system utilities from blowing up on 030 machines with no FPU. User space 
programs that need to use trig functions or other FPU implemented 
functions can be compiled with -m soft_float (or something along those 
lines) on those systems.
>
>
> Then i also noticed, that there seem to be some quirks. Eg. the IS_ZERO macro
> is defined as
> #define IS_ZERO(a) ((a)->mant.m64 == 0)
> But that condition is also true for infinities, and there are several places
> where IS_ZERO is used before checking for infinities. Eg. in the emulation of
> fmul https://github.com/torvalds/linux/blob/
> 7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/m68k/math-emu/fp_arith.c#L157
> +inf * +inf will return a NAN instead of +inf.

I'm sure the FPU emulation code can be improved a great deal. In this 
particular instance however, both operands are checked for infinity 
first. Only if the mantissa of (one of) those operands is zero will the 
NAN condition be raised.

I suspect this is mandated by some sort of standard - zero mantissa at 
infinite exponent makes no sense as a number.

> Next problem is the interaction between assembler/C. On entry, a2 is loaded
> with a pointer to the emulated FPU register set in the thread struct. However,
> all the arithmetic functions call out to C functions, which in turn callback
> some assembler functions like fp_long_ext2ext. At that time, a2 may contain
> any value. Won't that just crash, or did i miss something?

a0 - a2 and d0 - d5 are saved on the stack on entry in fpu_emu, and 
restored in ret_from_exception. What happens in between to these 
registers is up to assembly or C code. These registers are never 
expected to be preserved, so code can't rely on them having any specific 
content.

I cannot locate the specific assembly function you mention 
(fp_long_ext2ext). Can you post code or disassembly to illustrate the 
problem?

> Another problem: the fsqrt function seems to be broken when using arguments <
> 1.0. Eg. fsqrt(0.75) yields 1.7320508075. Looks like the returned exponent is
> off by one there.
That might be a genuine error in the sqrt algorithm there - can't see 
how it does arise though.
> So essentially: is that emulation actually used anywhere?

Not beyond the very basic stuff that did get implemented, no. You may 
have to look elsewhere for a feature complete FPU emulation (does netbsd 
have that?).

Cheers,

     Michael


>
>
>
>
>

  parent reply	other threads:[~2025-03-03 23:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 16:22 Software FPU emulation in linux kernel Thorsten Otto
2025-03-03 22:10 ` Brad Boyer
2025-03-04  5:24   ` Thorsten Otto
2025-03-04  5:48     ` Brad Boyer
2025-03-03 23:38 ` Michael Schmitz [this message]
2025-03-04  4:44   ` Finn Thain
2025-03-04  5:47   ` Thorsten Otto
2025-03-06 15:24 ` Thorsten Otto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=091d25fa-6a79-4685-a920-075611e79626@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=admin@tho-otto.de \
    --cc=linux-m68k@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).