Some time ago I suggested (in a side-note on a different topic) to introduce 
FAR as a C qualifier (similar to 'long').

So a far pointer would be 32 bit and the compiler would automatically produce a 
'conversion my lose significant digits' when it is used as near pointer, while 
any near pointer would be automatically extended to 32 bit 
where a far pinter is specified as argument.
Also, any function with the far qualifier would require a 32 bit pointer (and 
only those may be put into FARTEXT if there is not enough space in TEXT) and 
require to be called with CALLA and return with RETA.

Using an attribute makes the programmer responsible for the correctness of the 
various cobinations of near, far etc.
Making it a qualifier leaves this to the compiler and complies with the normal 
compiation flow, including function pointers etc.

It would possibly require, however, some tweaking of the linker.

Also, putting the init values for initialized global variables into FARTEXT (if 
it fits) would leave more space for NEAR functions. Also partly a linker thing. 

One reason for using near and far functions (where a far function may not call 
a near function) is that near calls are somewhat faster than far ones. And 
smaller.
Also, access to constants in near memory is faster than in far memory.

Even if the MSPs in question are faster and have way more flash than the older 
non-X devices, speed and size still matters.

JMGross

----- Ursprüngliche Nachricht -----
Von: kavaler
An: [email protected]
Gesendet am: 31.Januar.2010 23:04:14
Betreff: [Mspgcc-users]  suggestion: MSP430X far address warning


Something that would be useful in the MSP430X version of gcc would be to have
the compiler generate a warning (or error) when a user attempts to reference
a far function or data, without a cast.  This would apply if the -mdata-64k
is specified. The compiler now just generates bad code, assuming the far
pointer is 16 bits. A warning or error would at least allow the user to
clean up their code and find these bad references.

Robert


Reply via email to