Re: Tuple and changes for m68k with -malign-int
On Wed, 21 May 2025, John Klos wrote:
> > As I pointed out years ago, you need to stop wasting effort on
> > packages that aren't relevant anymore, due to bloat.
>
> There's no real point being made here. Which packages aren't relevant
> any more, due to bloat? Who decides?
>
Users do. I've said so several times.
https://lists.debian.org/debian-68k/2023/08/msg00023.html
https://lists.debian.org/debian-68k/2024/10/msg00024.html
https://lists.debian.org/debian-68k/2024/11/msg00019.html
> > And here's another thing you need to understand: there is no future
> > for a port that has no porter willing to identify relevant packages
> > and send patches upstream.
>
> This is a non sequitur. Reporting upstream is nice, but a port can exist
> without stuff getting reported upstream.
>
> While Adrian is obviously emotionally committed to improving Linux on
> m68k, the points he makes have reasoning, thought and explanations
> behind them. None of the arguments from you, Finn, make much sense.
> You're talking about irrelevant things and bringing nonsense examples in
> to the discussion. Your examples lack technical merit.
>
Perhaps you can show me the technical shortcomings of the patch I sent to
the python project?
> The issue really boils down to this:
>
> Should Linux maintain a 32 bit platform that has alignment issues
> because programmers make bad assumptions?
>
> Your argument is that ABI breakage is death, and that projects and the
> world are better when we tell people to fix their broken code.
>
No, that's not what I said.
> I agree that ABI breakage is a huge hurdle. At the same time, the ABI
> will change to fix 32 bit time. Is there any good reason to NOT switch
> to 32 bit alignment at the same time the time changes are made? I can't
> think of any reason.
>
> So can we all agree that there's no reason to not change alignment when
> the time changes are done?
>
We've been over that before too:
https://lists.debian.org/debian-68k/2023/08/msg00023.html
> Next, I also agree that programmers should not make padding assumptions.
> However, the real world shows us that there are way too many gatekeepers
> who scoff at the idea of supporting anything that's not Arm, amd64, or
> perhaps RISC-V. They don't care if their bad assumptions about floating
> point affect embedded platforms. They don't care if they've assumed that
> nothing of interest ever runs on big endian systems. Heck - they
> sometimes don't even care if things no longer compile or run properly on
> 32 bit x86!
>
> Dealing with them is tedious. Sometimes a private email to the right
> person in a project leads to a proper fix, and we don't even have to
> publicly talk about the fact that the failure was on m68k, VAX, Alpha,
> or whatever.
>
> I've done enough of this to know that it's far, far better a spend of my
> time to make things work by default where possible, and if not, to
> maintain local patches with an email sent off to good people so the
> gatekeepers can be avoided.
>
> If you think that the work of getting projects to care about edge cases
> isn't hard, then good for you - perhaps you should volunteer to do it.
I did that already:
https://lists.debian.org/debian-68k/2024/10/msg00042.html
> But at the same time I've seen you say you don't need and arent
> interested in these fancy new languages and packages, so I can't see you
> volunteering to do it.
>
> So if you're not going to volunteer yourself, then it's not really your
> place to suggest to others that they should be doing it instead of
> taking the easier route, which is to make more things work by default.
>
> > But, if it's not already dead, you will kill Debian/m68k if you break
> > the ABI contract.
>
> It's frustrating that you'd write this.
>
> Are there so few fans of m68k that this will kill Debian/m68k?
Once the ABI fragments, there is no "Linux/m68k" any longer. There are
isolated groups of users/developers with limited ability to collaborate
effectively.
> If so, then the 64 bit time change will kill Debian/m68k, and there's
> nothing anyone can do about it. So are you saying that the death of
> Debian/m68k is inevitable, and that we should all just give up? Anyone
> who still wants to run a modern OS on m68k hardware can still run
> NetBSD, after all. Right?
>
> Or maybe this WON'T kill Debian/m68k. And if it won't, then making two
> ABI changes at the same time is no different than making one. Right? So
> why not make the default alignment for m68k fit what programmers, who we
> all agree really shouldn't be assuming, assume for 32 bit so more things
> Just Work?
>
> I see absolutely no compelling reason given by you or anyone else about
> why this shouldn't be done aside from ABI change, and if if the ABI is
> about to change for time, then that reason becomes moot, doesn't it?
>
> Or do you or anyone else have a reason why it's not moot?
>
As I've said, I'm okay with a Gentoo/m68k profile for ABI experimentation
as long as the default profile tracks the upstream toolchain:
https://lists.debian.org/debian-68k/2024/10/msg00045.html
> > Nevermind removing that characteristic which provides it with a unique
> > advantage, being a smaller memory and cache footprint.
>
> This is ridiculous handwaving.
>
> If the memory footprint of software goes up enough to matter because of
> 32 bit instead of 16 bit alignment, then perhaps someone should tell
> people running the NetBSD/sun2 port. The very latest NetBSD runs on
> m68010 systems with actual 16 bit data busses in 4 megabytes of memory
> with 32 bit alignment. Think about all the memory they could save!
>
> Ok. That was a bit snarky, but do you really expect anyone to take this
> seriously?
>
Well, your handwaving is no more convincing than mine. Measurements are
welcome, though it's hard to know which hardware designs to measure.
> Likewise, do you really think that the overhead of unaligned access is
> outweighed by the fact that more stuff fits in the cache? Seriously?
>
Yes, some of my 68030 systems have 16-bit data busses.
As for the ones with 32-bit busses, I'd expect that two cache accesses are
generally faster than a long-word-aligned RAM access, though you may be
right about those algorithms that miss the cache.
BTW, my Apple Workgroup Server 95 has 512 KB of L2 cache. If I can get
Linux to run on it, I think it might provide some interesting
measurements.
> > Try to see the big picture. All ports will suffer the same fate as
> > this one: fewer users, commercial irrelevance, reluctant contributors
> > and bloated packages.
>
> What does any of this have to do with fixing alignment on m68k?
>
> > The relevance of m68k is now the way in which we respond to those
> > challenges. If the best that any port can hope for is ABI breakage,
> > we've failed.
>
> Are you here advocating for the termination of Debian/m68k? Or are you
> saying that alignment shouldn't be updated, and time shouldn't be
> updated? I really don't understand what you're suggesting.
>
> > One does not age gracefully by pretending to be young. m68k does not
> > contribute anything by becoming the same as every other 32-bit
> > big-endian platform.
>
> This is nonsense.
It is the main reason why porting to m68k leads to better code.
> The natural alignment for m68020, m68030, m68040, m68060 is 32 bit. That
> Linux didn't follow the SVR4 spec for ELF was an error.
>
> I really want to know:
>
> Who gets to make the call about whether or not the change is made?
>
Those with the time and skills to write the patches and the ability to
push them upstream to all the affected projects. Same as always.
Reply to: