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

[Jan Waclawek]

>>> I was just trying to hint a possible reason why the EI stuff was used at
>>> all, a possible idea which might have been abandoned later.
>
>Ah, ok. My original question was about how to improve the current situation so
>that it is easy to document, to understand and to use 

That's a noble intention, but please mind, that while the implementation of EI 
stuff (function pointers and table-driven switch/case, i.e. where gs() is 
inolved) in avr-gcc works (in a possibly suboptimal way), its counterpart in 
linker is buggy. 


>rather than elaborating
>the supposed history of avr-gcc ;-)

Well, I was trying to help.


>Not familiar with bolide devices and their applications, I wonder if users
>might completely rely on EIND = 1 and EIxxx throughout an application like boot
>loader that must not have jump pads in the lower segment.

The current implementation relies on EIND = 0 throughout the application; and 
apparently there are applications in the wild which happily live with that.

I did not suggest the "permanent" EIND as a future solution, only mentioned it 
as a possible reason for why extended indirections had been used at all.



>But code in libgcc already does PUSH zero_reg prior to RET to do indirect jump
>so that EIND does not work that way, anyway, in switch/case for example.


That sounds for me like a superior solution to trampolines etc., but I am not 
suggesting this as a final solution before thorough investigation. I guess in 
practice it might turn out to be a bit more costly than the trampolines, not to 
mention the work which would be needed to implement it (and which I am not able 
to do).


Jan