Re: [avr-gcc-list] May avr-gcc emit EIJMP/EICALL?

[Boyapati, Anitha]

>
>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