Re: [jamboost] Re: [BBv2] alignment feature and msvc assembler support

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-09-19 10:23:07

Reece Dunn wrote:
> Vladimir Prus wrote:
>>Hi Reece,
>>>2. alignment.diff
>>
>>I've some concerns.

I have similar concerns...

> Go ahead...
> 
>>1. What are use cases for <alignment>? If that's for specific layout for
>>specific structures, you've better off using pragmas, no? In that case,
>>there's little point in feature.
> 
> In large projects, especially where you are serializing/deserializing data, 
> having the correct alignment is *vital*. Granted, you could place pragmas 
> around these data structures, but what about types not in your control (e.g. 
> OS or standard structures) such as the point/rect structures provided by 
> various OSs?

The various OSs put specific alignments in the code with pragmas. Or 
assume, by testing and ABI restrictions, that the alignment is fixed. I 
haven't seen any project rely on build switches to guarantee alignment 
as it basically guarantee that it will break as soon as someone other 
than the writer uses the code.

> I am not sure of exact use cases, but what if you are using boost::serialize 
> to save window position information that will be processed by different 
> applications built with different compilers?

You guarantee portability with a _portable_ format.

> Compilers offer the ability to 
> locally control (through pragmas) and globally control (through the command 
> line) the structure alignment.

Not all compilers. Codewarrior has the former for assembly only, and the 
alignment for C/C++ can only be controlled through ABI terms not 
specific values. GCC also falls into the same mold as CW, you can 
specify alignments for some things but only for specific target 
processors and with limited tags not quantities.

> It is easy to say:
> 
> exe myapp : ... : <cxxflags>-align 8 ;
> 
> but this is (1) compiler specific (alignment is set with different switches 
> depending on the toolset), and (2) you can't auto-inherit alignment if you 
> say:
> 
> lib foo : ... : <cxxflags>/Zp2 ; # what does /Zp2 do again?
> exe : bar : ... //foo ; # oops - alignment mismatch
> exe : bar2 : ... //foo : <cxxflags>/Zp8 ; # oops - alignment mismatch
> 
> This is what the build system is for: provide a uniform mechanism for 
> configuring a build and reducing common errors.
> 
> Or what about different alignment/performance issues between 32-bit and 
> 64-bit platforms? I do not have experience developing for 64-bit platforms, 
> but there could be alignment issues here.

Sure they could, but they are usually enforced by the ABI specifications.

> Likewise, if you want to send data from a Windows application (built with 
> msvc) to a Linux application (built with gcc) using Boost.Serialization 
> using data out of your control (such as the C or posix date/time 
> structures), having explicit control over alignment can be one step to 
> producing binary interoperability.

And it's a last resort step if one can't use any other portable method 
of communications. For portability you would not send around chunks of 
data structures, but the fields of data structures. Which is what 
Boost.Serialization does.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org