Re: [arm-gnu] -funit-at-a-time

[Bryce Schober <bryce.schober@xxxxxxxxx>]

See replies below...

On 8/29/05, Charles Manning <manningc2@xxxxxxxxxxxxx> wrote:

> Is it just that the ordering of variables being emitted is not in declaration
> sequence? That would be a dangerous thing to assume, IMHO. All your
> assumptions should be in accordance with the C spec.

The answer to the above question is yes. I understand that I shouldn't
have assumed that, but in fact, it has been a "feature" of every c
compiler I've used before (which admittedly, isn't many). Behavior,
whether specified or not, tends to become expected.

> It sounds a bit like a similar problem I had when I needed to control
> placement of a flash header that looked like:
> 
> const unsigned image_length;
> const unsigned start_address;
> ... check sums etc.
> 
> 
> IMHO the correct way to do this is one of:
> 
> 1) Use an ld script to place things as you need them. You can use
> -fdata-sections to get individual sections for better placement granularity.

I'm actually already using an __attribute__ (( section <name> )) to
place the constants in a bucket to be handled in my ld script, but
it's not practical to create n sections in order to order n constants.

> 2) Use a structure for anything that is order dependent. To do otherwise is
> dangerous.

This isn't practical in my case, for reasons that I'd rather not get into...

> 3) Pull out special tables etc (eg. flash image headers) and put them in
> assembler files where you have a lot more control over what is going on. Then
> use a custom ld section to place this.

This gets clunky when you have assembly constant-initialize c
structures, doesn't it? It sounds like this would not be very easy to
maintain as things change over time. In fact, none of these options
sound very nice. Is deterministic emittance order really that much to
ask for?

> IMHO anyhing that requires pragmas or special C code syntax including
> attributes and __irq__ etc is broken. Most embedded code needs to be
> compilable with many compilers (eg. when you reuse code, or compile it in a
> test bed using a different environment), so anything that is not portable
> gets very ugly very quickly.

Embedded compilers _always_ have non-portable features, don't they? It
seems to me that yes, one should try to limit their usage of
non-portable features, but at some point there is a tradeoff between
code maintainability and portability. In reality, if you don't use
those features, you end up writing assembly that suffers in both
portability and maintainability. Typically the features added may look
different but will function similarly, and one can wrap the compiler
differences up in macros anyway, which to me feels like good
modularity and enhances the readability (read maintainability) of the
code.


-- 
Bryce Schober