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

[Georg-Johann Lay]

Jan Waclawek schrieb:
>>>> 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.

So then the binutily have to be fixed. avr-gcc already relies on relaxation.

You have a description of the bug? Just saw a rather lengthy chat on freaks
without pointing to the very problem...

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

It's not superior to jumping pads (I prefer that word over "trampoline" because
trampoline in gcc has different meaning), it is *using* them. The indirect jump
jumps to a pad located in segment #0 and this pad redirects to the actual jump
target.

> 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

24-bit pointers are not appropriate here with respect to their
effort-to-impement/gain ratio.

Aligning pointers to 4-byte as proposed by Denis is much more striking.
But that requires work to be done in binutils so that it can be used in the
compiler and it's an ABI change or extension.

Johann