Re: Intermediate step for new arch for lc040 compatibility

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > 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/e01bad87691572cf92a298cd4b2072ddd8a19554
 https://github.com/NetBSD/src/commit/b64bbce367ca2d4ea7dd36231c121a0bf3295d46

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