>
>RAMPZ is a different issue, we shouldn't mix them up and solve the problems
>independently.
>
>RAMPZ is set in __do_copy_data, __do_global_ctors and __do_global_dtors and
>thus set appropriately in __tablejump_elpm__.
>
>__tablejump__ does not use ELPM and assumes that jump tables are located in
>the
>lower segment as arranged by the linker script, see section .progmem.gcc*.
>
>The jump targets in jump tables from switch_case/.ctors/.dtors are located
>in
>lower flash and their entries are gs() and use relaxation magic to have
>jumping
>pads generated.
Ok. That explains it.
>
>Or did I miss something?
Not at all.
>
>>> Instead, programs for big targets should use linker relaxation and jump
>>> to the generated jumping pad by means of IJMP/ICALL instead.
>>>
>>> Thoughts?
>>
>> But this works only when the range is below 128K bytes. EIJMP/EICALL are
>> required beyond that. I think a proper fix will be to generate {EIND,
>> EIJMP/EICALL} instructions and then apply relaxation.
>
>Why that? Indirect jump IJMP/ICALL will jump to a jumping pad located in
>the
>lower segment which redirects to the final jump target by a direct jump
>that
>might target all of the address space. The overhead an time is 2 ticks
>which
>is no worse that fiddling with EIND.
Aah, indirect jump followed by a direct jump, ok, that works. (Initially I
mistook it as a series of ijmp/icall instructions). The main concern is
dependency on relaxation. Is not the relaxation supposed to be optional?
>Bottom line is that there is no need to ever touch or use EI gadgets, and
>EI
>should be removed from the compiler like so:
Sorry! I am late. I just hope that I got other conversations right.
I think we require EI* instructions eventually. As Jan points out, avr-gcc
dependency on relaxation does not sound right. Here are some of my preliminary
thoughts...
Consider some C snippet like the below, (may not have use, but an example for
illustration):
void (*func)(); //Function pointer
func = 0xF010A0A ; //Some assignment involving value more than 16-bit
(*func)(); //call the function
Assuming that avr-gcc can handle pointer assignment greater than 16-bit at some
point in near-future, should not the above code result in emitting 'EICALL'
instruction? I think it is cleaner to generate it this way than dealing with
jumping pads (and relaxation may be).
(off-topic - I saw in another post that avr-gcc already depends on relaxation.
Does this mean that relaxation must be turned for correctness of code and not
for optimization in some cases?)
Anitha
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
