Re: [ECOS] Compiling individual sources

[Rafael Rodríguez Velilla <rrv@tid.es>]

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

Bart Veer wrote:

> >>>>> "Rafael" == Rafael =?iso-8859-1?Q?Rodr=EDguez?= Velilla <Rafael> writes:
>
>     Rafael>   I want to compile individual files with -mlong-calls.
>     Rafael> Can I use the cdl script to distinguish which files must
>     Rafael> be compiled with this switch?
>
>     Rafael>   Maybe, the only way to customice individual files is
>     Rafael> using the make command. I'd want to put some of the eCos'
>     Rafael> functions in internal memory , but it will have problems
>     Rafael> to call the rest of the system if I don't use long-calls.
>
> Some eCos packages will allow you to manipulate the compiler flags on
> a per-package basis, but that is as fine-grained as things get right
> now. There is no support for manipulating compiler flags on a per-file
> basis.
>
> However, I suspect that you will want to use -mlong-calls for all
> files, not just for some of them. For example if you want to put a
> function like memcpy() into internal memory then either all modules
> that invoke memcpy() need to be compiled with -mlong-calls, or
> alternatively you need to give the memcpy() function the long-call
> attribute in a header file used by all code that calls memcpy(). It is
> not enough to compile just memcpy.c with -mlong-calls, that would not
> affect any calls to memcpy(). Obviously using -mlong-calls throughout
> will involve extra overhead for the system as a whole, which may
> outweigh the benefits of having some functions in internal memory.

  It is true that maybe in a well designed system the overweith of mlong-calls
would make the benefit minimal, but my system accesses a word in the external
memory after 8 cycles (it acesses it byte by byte with a wait state between
bytes), but the internal memory gets the instruction in just one cycle... surely
I will speed a lot my system  moving some functionality into the internal memory.

  About compiling it all with mlong-calls... I'm trying to avoid it, so if I can
put some critical functions into internal memory while leaving the rest compiled
without mlong-calls Ican improve the performance, leaving almost all the internal
memory to the programmer of applications.
  For example, I'm moving the IRQ mechanisms (part of vector.S) into the internal
memory, it has no api for external calls and only needs adding a pair of
pointers, but I expect that the performance will be boosted a lot. I'm also
moving the stacks into internal memory (that is almost inmediate).

  It is a pity that gcc can't decide when does it need a long-call and when not.


> Bart

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