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

[Charles Manning <manningc2@xxxxxxxxxxxxx>]

On Wednesday 31 August 2005 06:14, Bryce Schober wrote:

> > 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?

it is quite easy to do this in assembler. I just set things up as a small 
block of code in a file (eg.table.s):

	.text
	.code 32
	.global table

table:
	.long start_address
	.long ...


Another way of doing things is to use the ld functions that emit values., eg. 
something like:

SECTIONS {

.init_header : {
	LONG(start_address);
	LONG(...);
}
}

Of course one problem with the above is that you lose the C type checking etc.


>
> > 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.

I pretty much never use any of these special features, except the gnu 
structure assignment extensions when doing some Linux kernel stuff). The last 
time I did was at least 5 years ago.

Take for example a commonly used isr attribute provided by some compilers. 
What does this do? Sure it marks the code as being an interrupt service 
routine, but that is all. It does not tell you the true semantics: does it 
set up the stack for nesting or is it un-nested only? Does it re enable 
interrupts before entering the C function or not? Instead of just hoping the 
compiler does the right thing, I prefer to do this in ass'y because I then 
**know** what is happening.

Then once you've figured it all out, the semantics might change when you 
change compiler version or change from one compiler to another.

I often do my embedded systems algorithmic testing on a PC under Linux or 
Windows. That is, all the embedded hardware features are put into a HAL and 
hidden behind a common interface. Most (frequently 95%+) of the code is then 
run unchanged on the PC. This typically makes for far more rapid development 
than in-device development. THis would break with an over-dependence on 
special features.

In short, I think the best policy is to use C where it will work portably and 
use assembler etc when you start getting into the grey zone.

> In reality, if you don't use 
> those features, you end up writing assembly that suffers in both
> portability and maintainability.
But not predictability :-).
> 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.

To each there own, but expecting the semantics to be similar over versions and 
different compilers is perhaps ill advised.