[ECOS] Compiling individual sources

[ECOS] Compiling individual sources

[Rafael Rodríguez Velilla]

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

  I want to compile individual files with -mlong-calls. Can I use the
cdl script to distinguish which files must be compiled with this switch?

  Maybe, the only way to customice individual files is using the make
command.
  I'd want to put some of the eCos' functions in internal memory , but
it will have problems to call the rest of the system if I don't use
long-calls.



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

Re: [ECOS] Compiling individual sources

[Bart Veer]

>>>>> "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.

Bart

Re: [ECOS] Compiling individual sources

[Rafael Rodríguez Velilla]

[-- 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

Re: [ECOS] Compiling individual sources

[Bart Veer]

>>>>> "Rafael" == Rafael =?iso-8859-1?Q?Rodr=EDguez?= Velilla <Rafael> writes:

    <snip>

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

The compiler has no idea what code or data will end up where in
memory, that is the responsibility of the linker. Theoretically it
would be possible for the compiler to always issue a long call, and
then have the linker turn this into a short call if possible. Or have
the compiler always issue a short call, with the linker turning this
into a long call if necessary. However if the compiler does not know
exactly what instructions are going to end up in the final executable
then that is going to mess up any effort at optimisation. For example,
IIRC a long call requires an intermediate register so the compiler
would have to ensure that for every call operation there is a spare
register available. That is a big overhead for a problem that only
affects some code on some targets.

Arguably the underlying problem is that code generation is done by the
compiler rather than by the linker, and the former has insufficient
knowledge unless assisted by e.g. explicit attributes in the source
code. However this division of labour between compiler and linker is
not going to change any time soon.

Bart

Re: [ECOS] Compiling individual sources

[Rafael Rodríguez Velilla]

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

Bart Veer wrote:

> The compiler has no idea what code or data will end up where in
> memory, that is the responsibility of the linker. Theoretically it
> would be possible for the compiler to always issue a long call, and
> then have the linker turn this into a short call if possible. Or have
> the compiler always issue a short call, with the linker turning this
> into a long call if necessary. However if the compiler does not know
> exactly what instructions are going to end up in the final executable
> then that is going to mess up any effort at optimisation. For example,
> IIRC a long call requires an intermediate register so the compiler
> would have to ensure that for every call operation there is a spare
> register available. That is a big overhead for a problem that only
> affects some code on some targets.



  Well, I think that the attributes are a good compromise solution. Nowadays it
is very common to have MMUs that virtualize the memory space, and make long calls
unnecessary (but I don't have one ... and even MMU equiped micros must run
non-virtualized programs at least at boot-time)


> Arguably the underlying problem is that code generation is done by the
> compiler rather than by the linker, and the former has insufficient
> knowledge unless assisted by e.g. explicit attributes in the source
> code. However this division of labour between compiler and linker is
> not going to change any time soon.

  Anyway, we are extending on a non-eCos question, so thank you for your answer,
but let's stop boring the others with this talk... of course I'm available
through private email.



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