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: Denis Chertykov
Subject: Re: [avr-gcc-list] May avr-gcc emit EIJMP/EICALL?
Date: Fri, 14 Oct 2011 14:07:46 +0400

2011/10/14 Georg-Johann Lay <address@hidden>:
> 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?
>

I think so, but I don't use avr-gcc.
Do you know any real example of a program more than 128k ?

Denis.



reply via email to

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