Re: [avr-gcc-list] address lables for > 128k flash

[Sean D'Epagnier]

On 5/8/09, Tero Sinervo <address@hidden> wrote:
> Sean D'Epagnier wrote:
>> Any more thoughts on this?   Unfortunately address labels go in a void
>> * which seems like it should remain at 2 bytes.. so it's going to be
>> difficult.  Maybe instead of storing the absolute address, a relative
>> address could be stored from the beginning of the function.
>
> Look into http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>
> There's an interesting example:
>       static const int array[] = { &&foo - &&foo, &&bar - &&foo,
>                                    &&hack - &&foo };
>       goto *(&&foo + array[i]);
>
>
> That looks like a way to get relative addresses. So perhaps you could
> hack lc-addrlabels.h so that the local continuation object contains the
> function's absolute start address (set in LC_INIT()) and a relative
> address to the current location (set in LC_SET()). Then you'd have to
> use inline assembly to do an explicit RJMP in LC_RESUME() instead of a goto.
>
> This might still introduce problems if the function resides on the
> 64kword boundary.
>

Hi,

I don't think that's really that much better than just setting EIND
directly myself.. although it might mess stuff up later on if I don't
reset it when I return from the function.

> The switch implementation somehow doesn't seem so bad any more...

It does when you already have hundreds of proto threads written and
they all use switch statements.. it would be painful to convert to if,
and also ugly.  Maybe instead of address labels, I can have a switch
statement up front in the proto thread which jumps to the right place
using absolute gotos, then there is no problem of nested switch
statements, but it requires 2 indirect jumps (I could care less about
code speed/size for this)

In any case, we should disable address labels in gcc for >128k parts
since they are broken.. unless someone has an idea to fix them
correctly?

Sean