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

Le 7 janv. 2013 à 00:32, John Emmas a écrit :

> On 4 Jan 2013, at 18:54, Stéphane Letz wrote:
> 
>> 
>> The more difficult issue are the struct that are parts of the jack *public* headers to be used by clients applications  (like jack_position_t type for instance). We want to keep those struct 64/32 bits clean and not have their size change with a new release of libjack.dll, otherwise this would break the application compiled binary.
>> 
> 
> Stephane, that's precisely why I provided you with PRE_PACKED_STRUCT and POST_PACKED_STRUCT a year ago.  The idea was to move to 1-byte packing since most compilers support it and they all agree about the size and alignment of a 1-byte packed struct (which isn't true for any other value).  For example, gcc and MSVC both support 8-byte packing but they don't necessarily produce structs with identical alignment.
> 
> Admittedly there's a performance hit for 1-byte packing, given that it's not an optimal value for any modern CPU.  But when you're trying to accommodate different CPUs and platforms, you'll never find a value that's optimal in all cases.  Whatever changes you needed to make for the ARM platform, they've definitely changed the alignment between 1.9.8 and 1.9.10 so I guess that the structure packing concept has been abandoned.  I'd recommend _very strongly_ that you should take this opportunity to re-instate it.  In 1.9.8, the packing concept was deliberately introduced to make life easier from that point onwards but it seems to have been discarded almost immediately from what I've been able to observe in today's testing.
> 
> Another important benefit is that packing should allow the server to run clients - even if those clients were built using different compilers.  It's your decision of course, but I'd think that's highly desirable for Jack (in fact, almost essential).
> 
> John


Thanks for recalling this John. But the point is : how are we going to make jack2 work on ARM (where the PRE_PACKED_STRUCT and POST_PACKED_STRUCT based structs are not working because of alignment issues....) *and* continue to make it work on WIndows, possibly with different compilers?

Have you had a look at the new approach (defining JACK_ALIGN macros then "aligned types" like typedef JACK_ALIGNED_TYPE(double)   jack_double;.....) ? What happens exactly when compiling with different compilers on WIndows. Can you possibly test?

The problem here is to make jack2 evolved with new constraints *and* maintain the existing. We have to find a reasonable solution.

What do others think of those issues? (Paul, Nedko, Robin...)

Thanks.

Stéphane

1357542053.14664_0.ltw:2,Sa <7F8734EC-027F-468C-9C48-9F35B1519884 at grame dot fr>