Re: Tuple and changes for m68k with -malign-int
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
None of those links are relevant to a discussion about software bloat
and/or who decides if a package is suitable for m68k.
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?
"your examples" refers to the "irrelevant things and bringing nonsense
examples". Your replies that ignore what I'm clearly writing lead me to
believe you're not engaging in good faith. It was literally in the
previous sentence.
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.
You literally wrote, "But, if it's not already dead, you will kill
Debian/m68k if you break the ABI contract."
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
The discussion at that link offers no reasoning for not doing the
alignment change.
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
You half heartedly offered to help with projects that don't accept
upstream patches. Does this mean you also volunteer to contact them in the
first place? Have you contacted anyone directly yourself, aside from
sending an improved patch for python? For instance, have you contacted
anyone regarding any of the issues with the packages in Adrian's list?
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.
So what do you suppose will happen when the time changes are made?
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
Does this mean you want / expect the default profile to keep 32 bit time?
Well, your handwaving is no more convincing than mine. Measurements are
welcome, though it's hard to know which hardware designs to measure.
Nobody would ever argue that unaligned access comes with no or little cost
in overhead. They might argue that some modern processors pipeline enough
that the cost can be folded in to execution, but that's about it. It's a
well known fact of programming.
Calling my examples handwavy is childish, unless you want to argue that
the cost of unaligned access is in dispute. Do you want to do that? Do you
REALLY need measurements of something so well known? Or are you trying to
deflect?
My example of a low memory / memory constrained system that does very well
with 32 bit alignment is NetBSD/sun2. I don't have data, but I don't think
I need data when the very lack of someone saying, "hey - we really need to
save memory, but we're going to ignore this One Neat Trick in order to
save more of it" is sufficient.
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.
Those are two wholly different things.
The point you might be trying to make is that a cache miss on a system
with a 16 bit bus is more impactful than on a 32 bit bus system. Point
taken, but that's a rather small edge case (plus you've offered no
measurements to show the increase in cache misses that comes from 32 bit
alignment).
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.
Sure, but we're talking about one access, whether cache or memory, versus
two, cache or memory. The instance where one access to memory happens
instead of two to cache is very likely insignificant.
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.
Sure, but again, this has little to do with this discussion.
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.
I agree with that, but not fixing alignment so that m68k can remain the
canary in the coal mine isn't a good reason.
Look - there is an incredibly compelling reason to NOT do this change. I
agree with that wholeheartedly. The reason this thread bothers me so much
is because instead of discussing the one good reason, discussing possible
solutions and mitigations of impact, a lot of this discussion has been
derailed in to irrelevant and sometimes outright intentional diversions.
I really, really would like to see the discussion follow something like:
1) Are we doing this?
Separately, and without constantly going back to (1):
2) If we are going to do this, what will it look like? How will we do it?
How will we make things easy for users? How will we deal with
compatibility with old binaries? Will we use a new tuple? How is
compatibility with binaries using 32 bit time handled, and is what's
being done there applicable to this change?
John
Reply to: