Re: Tuple and changes for m68k with -malign-int

[Finn Thain <fthain@linux-m68k.org>]

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.