Re: [avr-gcc-list] address lables for 128k flash
I found an alternative way to solve my problem which just requires running a parser program on preprocessed code to generate switch tables for each protothread. This way the thread switches and each case gotos the right label. The actual code using proto threads doesn't know the difference. It requires two jumps (same as trampoline) but also is more complicated to compile source code. A better solution would be to support address labels in the trampoline the same way function pointers are supported. Then address labels would be fully supported. Does anyone have an hints on where to start with this? Thanks, Sean ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] address lables for 128k flash
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.
The switch implementation somehow doesn't seem so bad any more...
--
Tero
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] address lables for 128k flash
On 5/8/09, Tero Sinervo tero.sine...@elekno.com 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
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
