This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Re: long-calls in ARM
- To: Rafael Rodríguez Velilla <rrv at tid dot es>, "eCos-Discuss (E-mail)" <ecos-discuss at sourceware dot cygnus dot com>
- Subject: RE: [ECOS] Re: long-calls in ARM
- From: "Simpkins, Andy" <Andy dot Simpkins at Transcomm dot uk dot com>
- Date: Tue, 11 Sep 2001 09:15:20 +0100
> -----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
>
>
>