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

[Erik Christiansen]

First, many thanks everyone, for conducting the discussion here.

On 14.10.11 22:06, Praveen, Vidya wrote:
> Hello,
> 
> I hope we all agree that there is a bigger problem to be solved,
> whether we want to solve it now or not:

> 1. The compiler (C language in turn) supports a 16bit pointer 
> 2. AVR has a maximum address range of 0 to (2^22)-1 (JMP/EIJMP)
> 3. At present the largest flash that AVR has is 384Kbytes - requires 19bits 
> 
> Now,
> 
> What is that we are trying to achieve? 

Or, what can be achieved now (with limited resources), in a way which
leaves future improvements open?

The hardware supports 16 bit pointers plus 8 bit paging (EIND), but
there is reluctance to utilise that facility, because the AVR port of
gcc only handles 16 bit pointers, for hysterical raisins. It would
be a pile of work to upgrade that, AIUI.

The proposal to ".ALIGN 4" all functions, and then "pointer << 4",
quadruples the addressing range of existing 16 bit pointers, instead of
going to 24 bit pointers. AIUI, the pointer scaling _could_ be
unconditionally applied, since on smaller devices, the only penalty is
<15 bytes at the start of each function. (That only 12 pointer bits
would be used in a 64k device is no direct penalty.)
The resulting 20 bit address range covers 1M words, unpaged. That looks
awfully good for an 8-bit AVR.

But in that case, only assembler programs would use EIND, and who would
write such large assembler programs. (My largest for an AVR fitted in
64k with some room to spare, and that was a team effort.)

Jan's work with EI*, in libgcc, looks very interesting, but seems useful
only if we move to 24 bit pointers? Or is there a plan to introduce a
paged model to avr-gcc? 

> A. I agree EIJMP/EICALL is as good as IJMP/ICALL since the EIND is not
> used effectively given [1]. So it may OK to be changed now (as it is
> being discussed), what about the future devices which may have bigger
> flash?

Jan's work does use EIND. Using EIJMP/EICALL as synonyms for IJMP/ICALL
(through a requirement that EIND == 0), would seem to be a boobytrap
with painful future consequences, if 24 bit pointers ever come on the
AVR scene. I don't think that there are any benefits of confusing the
two.

> B. How can we generate jump pads for function pointers or tablejmp
> (and Label as values?) if the address cannot be deduced in the linker
> time as well. For example, what if the function address is a result of
> an expression that cannot be deduced in the compile/link time? 

Since these are generated by the linker, they can only exist for
addresses known at link time. However, if every function is given a
trampoline by the linker, then it is only necessary for the compiler to
use the trampoline address, rather than the function address. (e.g. the
DEFUN macro could publish the former, not the latter. (It wouldn't take
much to have DEFUN generate the trampoline, without further ado, I
think.)

> C. IMHO, the avr-gcc should not depend on the linker relaxation
> always. It can be optional but cannot be mandatory. If we have
> dependency already, may be in the future we should consider making it
> optional. 

Any problems with that are whizzing past me at the moment. ;-)

> D. If we don't want to move beyond supporting 16bit pointer, why we
> want to tweak the code generation to support longer jumps? Such as
> 256k or 384kb flash? In a way, aren't we misrepresenting the C
> language/ABI by doing so?
> 
> It looks like I am missing something in this conversation. It will be
> great if someone could enlighten me. 

A little more of the helpful explanation, which has accumulated
upthread, would really help synchronising understanding of a topic which
has had only light coverage in the past.

Erik

-- 
I have yet to see any problem, however complicated, which, when you 
looked at it in the right way, did not become still more complicated.
                                                         - Poul Anderson