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

[Praveen, Vidya]

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? 

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?

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? 

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. 

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. 

Regards
VP


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Boyapati, Anitha
> Sent: Friday, October 14, 2011 6:14 PM
> To: address@hidden
> Cc: Jörg Wunsch; Denis Chertykov
> Subject: Re: [avr-gcc-list] May avr-gcc emit EIJMP/EICALL?
> 
> 
> 
> >
> >RAMPZ is a different issue, we shouldn't mix them up and solve the
> problems
> >independently.
> >
> >RAMPZ is set in __do_copy_data, __do_global_ctors and __do_global_dtors
> and
> >thus set appropriately in __tablejump_elpm__.
> >
> >__tablejump__ does not use ELPM and assumes that jump tables are located
> in
> >the
> >lower segment as arranged by the linker script, see section
> .progmem.gcc*.
> >
> >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.
> 
> Ok. That explains it.
> 
> >
> >Or did I miss something?
> 
> 
> Not at all.
> 
> >
> >>> Instead, programs for big targets should use linker relaxation and
> jump
> >>> to the generated jumping pad by means of IJMP/ICALL instead.
> >>>
> >>> Thoughts?
> >>
> >> But this works only when the range is below 128K bytes. EIJMP/EICALL
> are
> >> required beyond that. I think a proper fix will be to generate {EIND,
> >> EIJMP/EICALL} instructions and then apply relaxation.
> >
> >Why that? Indirect jump IJMP/ICALL will jump to a jumping pad located in
> >the
> >lower segment which redirects to the final jump target by a direct jump
> >that
> >might target all of the address space.  The overhead an time is 2 ticks
> >which
> >is no worse that fiddling with EIND.
> 
> Aah, indirect jump followed by a direct jump, ok, that works. (Initially I
> mistook it as a series of ijmp/icall instructions). The main concern is
> dependency on relaxation. Is not the relaxation supposed to be optional?
> 
> >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:
> 
> Sorry! I am late. I just hope that I got other conversations right.
> 
> I think we require EI* instructions eventually. As Jan points out, avr-gcc
> dependency on relaxation does not sound right. Here are some of my
> preliminary thoughts...
> 
> Consider some C snippet like the below, (may not have use, but an example
> for illustration):
> 
> void (*func)();  //Function pointer
> 
> func = 0xF010A0A ; //Some assignment involving value more than 16-bit
> (*func)(); //call the function
> 
> Assuming that avr-gcc can handle pointer assignment greater than 16-bit at
> some point in near-future, should not the above code result in emitting
> 'EICALL' instruction? I think it is cleaner to generate it this way than
> dealing with jumping pads (and relaxation may be).
> 
> (off-topic - I saw in another post that avr-gcc already depends on
> relaxation. Does this mean that relaxation must be turned for correctness
> of code and not for optimization in some cases?)
> 
> Anitha
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list