On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote:
And since we have to break the ABI anyway to be able to use 64-bit
time_t
If you're worried about Y2038, aren't you jumping the gun? I reckon we
have about 10 years in which to figure out what a better m68k ABI should
look like.
I don't see any valid reason to stick to the problematic 16-bit
alignment used by the current ABI.
Well, here are a few reasons why all those padding patches you wrote were
a good thing (besides the obvious benefit of avoiding an ABI break):
- That code is now more portable among projects which care about
portability to 16-bit platforms etc.
- Explicit alignment reveals suboptimal cache footprint and wasted memory.
- Data structures often outlive the software that introduced them. It's
safe to say that the struct definitions you fixed will produce a benefit
you may never hear about, by virtue of code re-use.
...
If it's the former, perhaps you should not push it upstream. If it's
the latter, perhaps this redesign should seek to address real
shortcomings with the existing ABI, including problems which (for all
I know) may have entirely prevented some people from using it thus
far. That is, it should consider silicon beyond 680x0.
It's a historic architecture. We don't have to redesign everything.
Coldfire is still shipping (is it "historic" yet?). Not sure about Apollo
68080 and Buffee BP68040. Most likely TG68K and Pistorm will end up
gaining whatever features Linux requires (MMU etc.).
If we get the ABI right, such designs can benefit if it allows them to go
beyond 680x0 and better exploit the FPGA they may be implemented on.
(Dare I mention SMP?)
Considering just Coldfire for a moment, one question we could look at is,
how could the ABI be changed to permit the same binaries to work
efficiently on both kernels (CF and 680x0)?
It seems likely that ABI changes could potentially help to accelerate 68k
emulators.
Inefficient thread local storage is an issue that might be addressed with
VDSO calls rather than an ABI break.
