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

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

> 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.


>> - 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)


>> - 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.

Thanks,
---
Izumi Tsutsui