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
Reply to: