avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sean D'Epagnier
Subject: [avr-gcc-list] address lables for > 128k flash
Date: Thu, 7 May 2009 23:51:53 -0600

Hi,

I have been using protothreads extensively which can sit on top of
either switch statements, or address labels.  The second choice is
better because it allows you to use switch statements within the
protothreads.

Address labels is a gcc extension which allows you to store the
address of a label (normally you would goto it) into a void* type.
Then later you can goto the address, and it jumps to the label.  This
works flawlessly for 128k or less.. but when 128k is exceeded.. the
compiler actually emits wrong code without warning and the program
crashes.

I am looking for a solution to this.  One idea I had was to force the
protothreads into a section which is in the lower 128k.. unfortunately
I don't think I can do this without displacing data from the lower 64k
and currently the _P variations in avr-libc do not work if the data is
past the first 64k.

Another possibility is to somehow make sure no function crosses the
boundary at 128k.. so waste space here.  Then at the beginning of each
function that uses address labels, set EIND to the segment we are in.

Also.. since trampolines are used for indirect calls in the section
>128k.. why does gcc emit the eijmp and eicall instructions at all?
Does it even set the EIND register?  It appears not to, so if the EIND
register were set to something besides 0 (say 1) then the program
would break even though this doesn't seem like a reason it should.
Maybe gcc should instead only emit ijmp and icall?

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.

Thanks,
Sean




reply via email to

[Prev in Thread] Current Thread [Next in Thread]