This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM thumb interworking hole?


On Thursday 13 January 2005 12:41, Ian Lance Taylor wrote:
> Charles Manning <manningc2@actrix.gen.nz> writes:
> > From where I stand (ie. almost totally ignorant of gcc's guts), the way
> > code should be generated for handling a function pointer under vanilla
> > interworking is something along the lines of
> >
> >
> >         mov   rx,....  @ load rx with pointer
> >         bl      call_rx_trampoline
> >         .......
> >
> > call_rx_trampoline:
> >          bx  rx
> >
> > The rx_trampoline is very cheap (2 bytes) but needs to be close so it
> > matters little if this is emitted for every section that uses it. I'm
> > sure the compiler could emit this along the same lines as used to manage
> > literal pools etc.
>
> That is pretty much how it works today, except that there is only copy
> of the _call_rx_trampoline code, and it is in libgcc.

The interwork_call_via_rx has a whole bunch of interworking safety stuff in 
it too.

Anyway, you miss my main point.

On many devices you have memory areas that are more than 4MB apart and 
therefore cannot be spanned with a branch. Currently gcc does not handle the 
case of doing a long call to the interwork_call_via_rx code. THis means that 
it is currently impossible to use Thumb with some device memory maps.

>
> It's true that gcc could be changed to put that in the literal pool.
> But most people who use Thumb code are interested in minimal code
> size, so having one copy of the trampoline per program, rather than
> one per function which needs it, seems best in the normal case.  You
> have certainly identified a bug in the -mlong-calls case.  As Richard
> says, that bug is probably best fixed in the linker, which can insert
> the trampoline only when it is required.
>
> Anyhow, for ARMv5 code these issues do not arise.  Are you still using
> an ARMv4 processor?

There are very few ARMv5 parts available yet. There are a whole swag of very 
useful single-chip microcontrollers like the Atmel AT91xxx and Philips LPCxxx 
devices that are ARM7. They're small memory foot-print devices. 

"Upgrade to an ARMv5" is not at all a realistic way of thinking.

-- Charles


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]