Re: Tuple and changes for m68k with -malign-int

Hi Richard,

On Mon, Aug 28, 2023 at 2:12 PM Richard <[email protected]> wrote:
> On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <[email protected]> wrote:
> >On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
> >> > Not only mold but also most notably the following projects:
> >>
> >> a linker that is broken by a slightly unusual alignment isn't exactly a
> >> prime example.. if any project I would expect linkers and binary tools
> >> to pay attention to portability.
> >
> >Portable shouldn't mean having to accommodate for unreasonable design decisions
> >of other developers. It's perfectly fine to assume 32-bit natural alignment on
> >a 32-bit platform and I don't think it's fair to put the burden of adopting for
> >unusual design decisions on to upstream projects.
>
> Assuming anything that is not declared by the c standard is not good imho. The C lang is well known for its pitfalls and the basic binary tools ought not to set bad precedents ignoring those.
>
>  It is also reasonable to assume that on modern hw cache is filled in blocks of perhaps 1k or more and thus "unnatural" alignment might actually help performance because more fits into that one data burst.

"1k" (I assume you mean 1 KiB?) is a bit much...

Note that on several architectures you cannot do unaligned accesses,
so you have to declare such a structure with __attribute__((__packed__)),
and thus not only live with the overhead of doing unaligned accesses
from the D-cache, but also in emulating them in software...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds