Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Le 7 janv. 2013 à 13:53, Paul Davis a écrit :
>
>
>
> 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.
>
But we were dealing with those 32/64 issues with those PACKED struct right?
Stéphane
1357563361.13370_0.ltw:2,a <F251B10B-343C-4862-982A-ABC2AF575A9B at grame dot fr>