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: Fri, 14 Oct 2011 09:45:29 +0200
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

Denis Chertykov schrieb:
>> 2011/10/14 Jan Waclawek:
>>> Confused. EIND could be set once at program start (e.g. to 1) and then
>>> left so forever but avr-gcc requires EIND = 0?
>> 
>> No. You are mixing two independent answers.
>> 
>> 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 rather than elaborating
the supposed history of avr-gcc ;-)

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.

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.

>>> 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?
>> In my humble unqualified and unimportant opinion, it does not really
>> matter.
>> 
>> As it is now, the EI stuff relies on EIND being permanently 0, thus can be
>> replaced by plain IJMP/ICALL. But since that happens, it does not matter
>> what is the value of EIND anymore.
> 
> I'm agree.
> 
> Denis.

This means that a patch to remove EI* from avr-gcc is fine?

Johann




reply via email to

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