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.