[ECOS] Re: long-calls in ARM

[ECOS] Re: long-calls in ARM

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

> 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

RE: [ECOS] Re: long-calls in ARM

[Simpkins, Andy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

> -----Original Message-----
> From: Rafael Rodríguez Velilla [ mailto:rrv@tid.es ]
> Sent: 11 September 2001 07:48
> To: ecos
> Subject: [ECOS] Re: long-calls in ARM
> 
> 
> > 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 ;) ). 

	yes I would be very interested...

> But I suppose that not many people has 
> such big differences
> between the behavior of their internal memory and their 
> external memory as me.
> 
> 

	Fast EDO RAM internal to the ASIC and slow (8 Wait states) SRAM
Externaly, I have my Interrupt stack running using the EDO RAM, fortunatly
this did not require -mlong-calls because they reside close enough togeather
in the memory map

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