avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] May avr-gcc emit EIJMP/EICALL?
Date: Thu, 13 Oct 2011 18:07:27 +0200
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

Denis Chertykov schrieb:
> 2011/10/13 Jan Waclawek:
>> 
>>> 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.
>> 
>> AFAIK, the linker creates the trampoline/jumptable regardless of
>> relaxation. It's just that in certain (in practice most) cases this
>> process is broken UNLESS relax is used. 
>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=707285#707285
>> 
>>> 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:
>> As it is now, yes. But there might have been a reason for the EI back
>> then.
>> 
>> Imagine for example that all targets of indirect jumps are within one 64kW
>> "segment". Then, the "segment" register EIND could be set once at the
>> beginning and left so forever; and there's no need for the trampolines.
> 
> I'm agree. Right now the AVR port have a support only for 16bits addressing
> for program memory. It is a 128k bytes and 64k words. Lets say "The current
> AVR ABI require EIND == 0". If user change it implicitly then EIND must be
> restored to 0.
> 
> Denis.

Confused. EIND could be set once at program start (e.g. to 1) and then left so
forever but avr-gcc requires EIND = 0?

So the conclusion is to do nothing about it and let things as they are and rely
on EIND = 0 and if EIND = 1 the user must not blame the compiler?

Johann







reply via email to

[Prev in Thread] Current Thread [Next in Thread]