[ECOS] Re: long-calls in ARM

[Rafael Rodríguez Velilla <rrv at tid dot es>]

> Impossible, in fact.  The compiler doesn't know at the time it generates the
> code what the relative positions in memory will be of the caller and the
> callee.
>
> It would be possible to add code to the linker to synthesize a long call stub if
> it turned out that a branch was out of range, similar to how glibc's dynamic
> linker handles R_ARM_PC24 branches between shared libraries.  There would be a
> run-time performance hit for this, so you'd need to judge whether you'd get better
> results than by just turning on -mlong-calls and taking the overall hit;
> obviously it depends on the mix of long and short calls in your application.


  Just spotting some key functions and adding a pair of attributes to put them in the
internal memory, and adjusting its calling attributes has halved the time required by
my system to attend interrupts.
  The price to pay is that I have had to modify vectors.S, and two prototypes of
intr.hxx... I'm loosing some compatibility.
  Obviously, compiling it all with -mlong-calls  will slow my system too much.

  Maybe some other people are interested in seeing a cdl option that allows them to
move critical sections into their fastest memory, as me, it wouldn't be difficult (I
have done it ;) ). But I suppose that not many people has such big differences
between the behavior of their internal memory and their external memory as me.





--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270