[avr-gcc-list] Re: [Fwd: Re: Allocating variables to a fixed address]

[David Brown]

Robert von Knobloch wrote:
> Jan Waclawek wrote:
> > > I simply require a way to fix absolutely this jump table in memory.
> > > Whether I write it in C or assembler seems to me to be irrelevant, as is
> > > using an array of pointer to functions, because I still have the problem
> > > of fixing these at absolute addresses.
> > >
> > > If anyone knows a way to do this, I would very much appreciate it.
> > >     
> >
> > The attachment illustrates what I mean by jumptable in asm, and its usage (see main). Address of .mysection was fixed to 0x00FF by passing it to the linker through avr-gcc ("-Wl,--section-start,.mysection=0xFF00"). 
> >
> > It of course can be a separate asm file, and the individual lines can be 
> > generated by a handy macro; but those are only unimportant details.
> >
> > Enjoy! ;-)
> >
> > JW
> >
> >
> >
> >   
> Thanks Jan,
> This is effectively what I have done, except I used C stubs instead of
> assembler:
>
> [.section origin is at 0xff00]
> void test_func_1(uint16_t foo)
> {
>     func_1(foo);
> }
> void test_func_2(uint16_t foo)
> {
>     func_2(foo);
> }
>
> Why would the compiler respect assembler any more than my C calls (it
> changes the order of them as they are stored in memory, so I cannot
> guarantee the address of "test_func_1()")
>
> If GCC will respect the order of the assembler jumps (and thus the
> absolute address) then that is my easiest solution. At the moment I
> can't really see any difference between assembler and C here. Or does
> someone know better ?
>
> You see I really distrust the compiler now :-)
>
> Robert

Not only can the compiler re-order the function, but it can also use 
different sizes for each function (for example, the size may depend on 
the number and type of parameters and return type), and it can optimise 
the code in different ways (such as by inlining, or by removing unused 
functions).  The only way in C that you can guarantee the ordering and 
consistent offests is to use a table of function pointers.

There are ways to get it sort-of-right, if you want to maximize your 
efficiency and avoid the pointer and indirect call.  You can use an 
optimisation flag to avoid re-ordering the functions (I can't remember 
the flag, but now you know it is there, you can look it up!), and 
function attributes to force code generation even though the function 
appears unused, and to force non-inlined generation.  You can then use 
some post-processing on the map file and generate a matching interface 
file to use in the plugins - with enough unpleasant macros and type 
casting, you should be able to produce something that can be used as 
normal function calls in the plugin and compile to a call in the main 
program.  However, it would be a lot of work for very little gain - a 
table of function pointers would be very much easier to get right.