Re: CVS commit: src/sys/arch/m68k/m68k

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

On Sun, 13 Apr 2025 08:28:04 Izumi Tsutsui wrote:
> > Would you or isaki@ or martin@ like me to assign PR 13078 to either of
> > you and I'll write a followup email to the binutils people stating that
> > from now on you'll handle all responsibilty for the correspondance with
> > them and assign either of you to the doc/HACKS note.
> 
> Actually I had not noticed PR/13078 and XC68LC040 errata until
> I saw the following post:
>  https://mail-index.netbsd.org/source-changes-d/2024/10/30/msg014315.html
> 
> I think the conclusion was mostly mentioned in the post.
> 
> Possible options were already proposed, then we should consider
> the "decision" by The NetBSD project and NetBSD/m68k users,
> rather than technical implementation details.
> 
> >> I think this is impossible w/o compiler/linker support and doing special
> >> userland builds for the affected CPUs.
> >> 
> >> Possible workarounds:
> >> 
> >> - use softfloat userland
> 
>  pros: less overhead than "FPU_EMULATE" on kernel side
>  cons: requires to define proper MACHINE_ARCH (m68ksf etc.) and prepare
>        two set binaries (at least for mac68k) like evbarm-earmv6{,hf} etc.
>        by updating build.sh and release binary sets in src/distrib etc.
> 

Soft float did not work and was not an option on m68k - I even and was 
questioned for it adding missing source defines for libm :(

Why not have a build with -lcfix turned on say m68k-something or other?

> >> - replace chip with a fixed LC040 or a full MC040
> 
>  pros: no extra work is necessary
>  cons: no workaround for XC68LC040 users, and MC68LC040 is rare?
>        (but XC68040 just works)
> 

This is not possible for me as it would require a small outline surface mount 
package chip for my powerbook and the the expense of getting someone to 
replace it for me.  Multiply that by all users of XC68LC040 users who can now 
use NetBSD due to -mlcfix.

> >> - use userland compiled so that it has a NOP before any FPU instruction
> 
> a) apply the workaround to all m68k ports:
>  pros: same m68k binaries can be shared
>  cons: requires extra performance penalty for all m68k (020/030/040/060)
> 
> b) apply the workaround only for XC68LC040 users:
>  pros: nothing? (only technical interests of developers?)
>  cons: more extra overhead than softfloat binaries
> 
> 
> IMO, the second option (i.e. "unfortunately we won't support XC68LC040")
> seems reasonable.
> 
> On the other hand, I'm afraid "-mlcfix" options won't be accepted
> by most m68k users because we have very few LC040 users and
> the LC040 FP problem has been well-known for >30 years.
> 

Its for the first time in 32 years this has been fixed...... All of these 
options were in PR 13078 which I read and reopened and wrote the fix as 
proposed in the PR for gas(1).

Now that this has been fixed it raises the possibility of supporting all m68k 
(even buggy XC68LC040) cpus.....AND THATS THE POINT!!!

Nat