Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)

On Mon, Jan 7, 2013 at 7:32 AM, John Emmas <[hidden]> wrote:

> On 7 Jan 2013, at 11:58, Paul Davis wrote:
>
> >
> > I think that you (John) are missing the issue with alignment. It is not
> that gcc on ARM cannot implement single-byte packing. The problem is that
> the processor will raise an exception when attempting to load or store
> values when this alignment violates the rules for the processor.
> >
>
> I understand what you're saying Paul but I'm afraid I can't agree - unless
> ARM is some kind of special case.  I can see your point about
>  __attribute__((packed)) meaning "I know what I'm doing" and I'm sure that
> used to be the case with older architectures but things have moved on.
>  Where a compiler supports struct packing (and at the point when the data
> needs to get presented to the CPU) it's the compiler's job to re-adjust the
> data as needed, to match the CPU's preferred alignment.  Of course, if the
> compiler can't handle that for some reason it should issue a warning, just
> like you said - but if the compiler simply presents misaligned data to the
> CPU, then the compiler doesn't really support packing.
>

there is nearly always more than 1 way to skin a cat or pack a C structure.
if __attribute__((packed)) has *any* room for interpretation, or if there
is more than 1 way to pack a given structure to follow processor rules,
then it does not accomplish your stated goal of ensuring compatible
structure layouts between compilers.

and i want to remind all readers that this discussion is ONLY about that.
this has nothing to do with 32/64 issues. it is solely about  ways to
compile JACK with a compiler that uses one packing convention and end up
with something usable by a client built with a different compiler.

1357563205.13323_0.ltw:2,a <CAFa_cKmFut9NHEV0B-RCjV0BtvG-R5WXiACXkRDUk01znQ85yg at mail dot gmail dot com>