Re: Intermediate step for new arch for lc040 compatibility
Romain Dolbeau <[email protected]> Sat, 3 May 2025 17:39:45 +0200
| Newsgroups | gmane.os.netbsd.ports.m68k |
|---|---|
| Message-ID | <CADuzgboek2H9j3_JVZWwCDt+2hQ-g48f_+QjBnC-AY9qqacOPQ@mail.gmail.com> |
Le sam. 3 mai 2025 à 17:22, Nat Sloss <[email protected]> a écrit : > 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. While I love the idea of demonstrating a fix for that particular issue, I don't see much of a practical point at the distribution level. m68k CPUs need all the speed they can get, so extra nops everywhere are a big no-no for systems with FPU and systems with non-buggy F-trap support. * Systems with FPU don't need it / don't want it * Systems without FPU and no bugs ('020, '030, debugged MC68LC040) don't need it / don't want it * Systems with the buggy XC68LC040 are the only one where it offers a solution However, this is only for those *using hard-float binaries*. And that's where I'm confused. While I do see why one would want to run a standard distribution on XC68LC040, why hard-float? It makes a lot more sense to me to just run a soft-float distribution on any FPU-less system. And it will be faster, as the FP emulation code doesn't need the overhead of the F-traps. I must confess I don't even know if there's a soft-float variant of NetBSD/m68k (all my systems running NetBSD have FPU for now, though I'm considering a home-made one with a FPU-less MC68040V), but for me it would make a lot more sense to use that (and add it if it's missing) rather than a XC68LC040-specific variant. Sure a bunch of Mac LC475 shipped with those, but ultimately it's probably easier and more convenient to either upgrade them to full '040 or bug-free MC68LC040, or to run soft-float on them. Cordially, -- Romain Dolbeau