>>> 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
