Re: Plan needed for switching m68k to 32-bit alignment

On Sun, 2024-10-27 at 13:49 +1100, Finn Thain wrote:
> I think that's overstating the case. Alternatives to rust are available 
> and will be for the foreseeable future. Most notably, 
> https://safecpp.org/draft.html

It's not just about Rust:

> https://people.debian.org/~glaubitz/alignment-meme.jpg

> I agree with your sentiment though, in that rust generally gets a lot of 
> funding and hype. Even if the Rust Foundation doesn't care about 
> supporting the backend for m68k, there is still a way for non-commercially 
> viable platforms to collaborate. In particular, 
> https://gcc.gnu.org/wiki/RustFrontEnd

This is getting off-topic.

> > > Absent the right conditions, perhaps it is best focus limited porter and
> > > developer effort on patching only those packages that are really required.
> > 
> > I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
> > and that was without even getting to something I could put to a
> > compile and runtime test.
> > 
> 
> I take your point about the amount of effort required (and the lack of 
> resources). The answer may be to share the work better by enabling more 
> collaboration.

The "collaboration" currently means me doing 100% of the Debian/m68k work.

> It appears that NetBSD/m68k has naturally aligned ints. Perhaps you could 
> look at adding kernel support for their ABI, and get access to Qt and LLVM 
> that way, without impacting the existing ABI and its ecosystem.

What ecosystem? Do you honestly care that any hobbyist cares about having
to reinstall their retro computers?

> BTW, it has long annoyed me that two different 68k Mac bootloaders exist, 
> one each for Linux and NetBSD, which are duplicated effort, and have 
> different sets of bugs. To my mind, this is another good opportunity to 
> collaborate and avoid wasted developer effort (perhaps by dual licensing).

Again off-topic.

> > “Natural” alignment of data types has essentially become a requirement 
> > these days, and m68k is the only true outlyer (i386 could in theory, but 
> > the Unix psABI designers were sensible enough to not do it).
> > 
> 
> I expect alignment assumptions like that will end up putting more 
> platforms in the same predicament in future. "Natural" alignment is 
> meaningless in the context of portable data structures, as they exist 
> without reference to any particular integer unit. It is because your 
> struct patches improve portability that I'd expect those patches to remain 
> acceptable upstream.
> 
> Q. What is the size of this struct, assuming baa.b is naturally aligned?
> 
> struct baa {
>         int a;
>         long long b;
> };

We're dealing with today's software and not something that exists in 50 years.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913