Re: [avr-gcc-list] Why are we using EICALL and EIJMP for AVR256?

[Dusan Ferbas]

Ok, I modified the wiki page. Is it correct now ? I assume 
trampolines are generated only for calls to functions, that reside in 
upper half.
Anyhow, placing functions manually to lower half still generates 
smaller and faster code.

Trampoline area for a bootloader - where will you place this code 
(jmps) if beginning of flash is still erased, while bootloader code 
is running (at end of flash).

Dusan

At 02:45 18.12.2009, Andy H wrote:
> You misunderstand.
>
> I said Wiki is misleading. Not that your solution for bootloader is 
> wrong. For example:
>
> "So in fact *eicall* instruction with current avr-gcc cannot call a 
> function in upper half flash."
>
> Whereas avr-gcc can indeed call functions anywhere.
>
> It is not possible to handle EIND inside gcc (before gas and 
> linker). Pointer are only 16 bits -so there is nowhere to put a seed
> associate with each pointer.
> If it were possible within gcc I assume seeding would be slightly 
> faster since JMP is 3 cycles and STS is 2. As you
> discovered, EIND would need to be saved by ISR or interrupts 
> disabled while jump occurs - thus overall unlikely to win.
>
> I do not quite understand why bootloader does not use its own 
> trampoline in lower memory. As this would leave EIND=0 and permit
> simplification to IJMP/ICALL - thus leaving EICALL/EIND free for 
> assembler or more exotic usage.
>
> Kindest regards
> Andy
>
>
> Dusan Ferbas wrote:
> > Hi Andy,
> >
> > believe me, we tested, debugged and it is running now in a lot of 
> > devices for several months.
> > Did anyone tested if seeding the EIND before every eicall is slower 
> > and with bigger code size ?
> > (in comparison to trampolines)
> >
> > Even if I admit using trampolines in a bootloader code (we are 
> > counting every byte),
> >  you have a problem, because 1st, only the bootloader is flashed
> >  and also trampolines differ for every application. The bootloader is same.
> >
> > BL is linked with LDFLAGS = 
> > -Wl,-Map=$(TARGET).map,--cref,--defsym,__stack=$(StackAddr) \
> > -nostartfiles -nodefaultlibs -Ttext=0x01F800
> >
> > Dusan
> >
> > At 01:30 18.12.2009, Andrew Hutchinson wrote:
> > > ...
> > > For 256 devices avr-gcc uses linker trampolines to allow 16 bit 
> > > function pointers to reach any  function located anywhere in address map.
> > >
> > > The EIND is set to zero by gcc. (Trampolines are located in lower memory)
> > > When a function pointer is assigned the address of  function (in 
> > > upper memory), a full sized jump to the function is added to trampoline table.
> > > The function pointer gets the 16 bit address of this entry.
> > >
> > > When the jump occurs - using EICALL, it will jump to trampoline 
> > > using 16 bit address and EIND set to zero. The trampoline JMP will 
> > > then take it to the function.
> > > If the function is in lower memory, the trampoline is not created 
> > > by linker (though I have not checked that!)
> > >
> > > Andy
> > >
> > >
> > > Dusan Ferbas wrote:
> > > > Hi, your case is, that a bootloader (BL) uses trampolines.
> > > >
> > > > I described a case in this list (June 2008 and Mar 2009), where 
> > > > an application calls a BL, where eicall resides.
> > > > There is a wiki page about it: 
> > > > http://www.ethernut.de/nutwiki/Nut/ATmega256x
> > >
> > > Dusan