> 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
