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

On Mon, January 7, 2013 3:58 pm, John Emmas wrote:
> And after all that manual adjustment, what happens if the same code needs
> to run on a different CPU with some other native alignment?  Chris, this
> is just a roundabout way of saying that the ARM compiler doesn't
> understand packing.

Let me back up a minute and make sure I have not misunderstood something.

I thought the original suggestion was not to use a general pack directive
to the compiler, but specifically a pack(1) directive.  If I understand
the syntax correctly (which is not a sure thing) that would say to pack on
byte boundaries, which implies no padding bytes between structure members.

If I do not have a mistake in my understanding as described above, how is
that a compiler problem?  The programmer has instructed the compiler to
pack elements with no padding bytes, which would work if all the data
elements in the structure occupy 4 bytes, but which results in a load
exception if any of the data elements are smaller than 4 bytes.

That to me says the programmer should not use pack(1) unless the
programmer understands the implications.

The documentation for the Microsoft compiler points out that if you pack
your data structures, you may need to use the _unaligned attribute when
accessing the struct to let the compiler know that extra code needs to be
generated to handle the unaligned data.  The _unaligned directive does
nothing on some platforms, but adds the additional code on platforms where
it is needed.
http://msdn.microsoft.com/en-us/library/ms253935%28v=vs.80%29.aspx
http://msdn.microsoft.com/en-us/library/ms253978%28v=vs.80%29.aspx

GCC does not seem to have the equivalent of the _unaligned directive, so
on platforms which can not handle unaligned access, either the programmer
must add the additional required code by hand, or avoid packing structures
in ways which cause unaligned access.

> accommodate that.  Nowadays (far from gaining performance benefits)
> there's almost always a performance penalty in changing a compiler's
> default packing alignment.

Yes, but isn't that what you had first proposed?  The default packing
alignment is not going to be on byte boundaries on any platform which can
run jackd.  Did I misread an earlier message?  I thought you had suggested
pack(1).

> This is because when data is taken from RAM
> and presented to the CPU, the compiler must adjust the
> alignment as needed and do the reverse again on the way back to RAM.


That is what the compiler does by default. When you use the pack directive
you are in essence telling the compiler that you know something that the
compiler does not have access to, so trust the program input, override the
default behavior.  The default behavior on ARM would likely be something
equivalent to pack(4).  Using a pack(1) directive causes the default
behavior to stop.  I don't think it is a valid complaint against the
compiler when something breaks after instructing the compiler to stop 
using the correct default behavior and start using a different behavior.


-- 
Chris Caudle

1357602068.15335_0.ltw:2,Sa <ffb822b9dbca9bfa764dd5aa04d62434.squirrel at email dot powweb dot com>