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