Re: Intermediate step for new arch for lc040 compatibility

[Nat Sloss <nathanialsloss%yahoo.com.au@localhost>]

On Tue, 29 Apr 2025 15:27:29 Izumi Tsutsui wrote:
> > > My question is "Why don't you try to make soft-float work on m68k"
> > > if special (non-default) binaries are necessary for XC68LC040?
> > > 
> > > What's the actual problem on it?
> > 
> > These are the reported failures and test results from a soft float
> > installation:
> > 
> > http://ftp.netbsd.org/pub/NetBSD/misc/nat/lc040-atf-softfloat.report
> > http://ftp.netbsd.org/pub/NetBSD/misc/nat/lc040-atf-softfloat.out
> > 
> > As opposed to 14 failures with this change (same for mc68030 with fp
> > emulation and a full '040 in quemu).
> > 
> > And the only other concern with soft-float is abi incompatibiity if
> > running the binaries on a hard float system (I don't even know if that's
> > possibile).
> > 
> > At least with this change the binaries produced by an -mlcfix toolchain
> > can run on any existing m68k system without special requirements.
> > 
> > Then efforts can be unified fixing the libm/tests and or fp emulation for
> > all m68k cpus.
> > 
> > That's my rationale...
> 
> My rationale was already posted to in source-changes-d, but I'd like to
> revise it in your comments.
> 
> ---
> 
> (1) Use soft-float userland
> 
>  Pros:
>  - Lower overhead compared to kernel-side "FPU_EMULATE"
>  - Easier to maintain with future toolchain updates
>  - Much simpler and more straightforward to prepare soft-float binaries
>    for NOFPU CPUs, compared to kernel-side FPU_EMULATE with m68klc
>    bug workaround for gas and build.sh structures
> 
>  cons:
>  - Requires definining a new MACHINE_ARCH (e.g., m68ksf) and
>    maintaining two set of binaries (at least for mac68k) as with
>    evbarm-earmv6 vs evbarm-earmv6hf; also requires updates to
>    build.sh and release binary sets structures in src/distrib etc.
>  - Some work may be needed to impelment incomplete soft-float funtions
> 
> 
> (2) Use userland compiled with a patched gas (e.g, inserting a NOP
>     before all FPU instruction), only for XC68LC040 users
> 
>  Pros:
>  - In theory, the same binaries might work on non-XC68LC040 systems
> 
>  Cons:
>  - Higher runtime overhead than soft-float
>  - Not all FPU instructions are emulated properly
> 
> ---
> 
> You wrote that "soft-float is abi incompatibiity if running the
> binaries on a hard float system" as a pro of your m68klc,
> but I don't think that is quite accurate because:
> 
> - If we go with soft-float, it should have a distinct MACHINE_ARCH
>   (e.g., m68ksf), as is the case with earm vs earmhf
> 
> - It would also cause problems for XC68LC040 users mixing default
>   and "m68klc" binaries, if they share the same MACHINE_ARCH
> 
> 
> From the current patch and discussion, it's a bit hard to see
> whether the underlying design considerations have been fully
> thought through.
> 
> It gives the impression that the goal is more about applying
> a workaround that happens to make things work, rather than
> understanding and shaping the intended architecture.
> 
> Similarly, reviews should ideally be a space to validate and
> refine design choices, not just to collect approvals against
> already-implemented code.
> 
> Taking a step back to clarify the problem (especially on the
> soft-float side) and intended direction could really help
> the quality and maintainability of the work.
> 
> 
> Also, the area you are modifying has been maintained by
> other developers over time, including those responsible
> for imported third-party toolchains.
> 
> When proposing changes here, it's also important to consider
> the maintenance impact on those developers as well.
> 
> Currently only isaki@ maintains the FPU_EMULATE code for m68k,
> based on his own emulator work.  Very few other developers
> are actively working in this area:
>  https://github.com/NetBSD/src/commits/trunk/sys/arch/m68k/fpe
> 
> For example, even basic sin(3) and cos(3) had not been implemented
> in m68k/fpe, and even xeyes(1) didin't work correctly:
>  https://github.com/NetBSD/src/commit/e01bad87691572cf92a298cd4b2072ddd8a19
> 554
> https://github.com/NetBSD/src/commit/b64bbce367ca2d4ea7dd36231c121a0bf3295
> d46
> 
> I assume mrg@ will work on future binutils updates,
> but I wonder whether your current m68klc patches account
> for that eventual merge direction.
> 
> Thanks,
> ---
> Izumi Tsutsui

You wrote on source-changes-d:
You are ignoring cons of your options.

Please ask m68k users first, if it's acceptable or not.

---
Izumi TSutsui

And thats what this is.....despite the pros and cons.

Soft-float was never offically supported on m68k it was a finge case so this is 
another way to handle the lc040s before (one or both) changes are supported.

I've upstreamed the patch with binutils as stated in previous commit logs and 
very public discussions on NetBSD mailing lists to which you have replied to.

The links to the post to the binuilts people can be found there.

So far they have not returned correspondence or interest in this issue (its a 
shame I'm 20 years late), but if they do reply and commit this change or 
equivalent there will be no burden of maintence locally.

In the event they don't and the changes are still deemed of interest the patch 
to gcc was much smaller (and hence easier to maintain) than my original patch 
patching all f* instructions in gcc instead.

So this is really me asking the remaining m68k users if there is interest in 
this approach and eventually (hopefully sooner than later) a new arch m68klc.

If you deem it necessary to ask users on m68kla if they would like netbsd to 
run on the lc040 i shall :(


Best regards and thanks for looking at this,

Nat