The reason I am suggesting generating a warning (or error) when a 20 bit pointer is reduced to 16 bits is because this seems like a pretty easy thing to implement for someone familiar with gcc (which I am not). Implementing 20 bit pointers by using the msp430x instructions seems to be much more difficult (there is a comment to that effect in the todo list). Implementing 20 bit pointers as 32 bit pointers would yield a much slower implementation since msp430x instructions are only 20 bit.
While it would be nice to write the compiler such that it could optimize calla/reta instructions into call/ret instructions I am not sure if this is really feasible with gcc. The only functions that could make use of this optimization are functions that 1. are linked at low memory, 2. are only called from low memory, and 3. are not called indirectly (i.e. are not referenced anywhere other than in calla instructions). Only the linker has all this knowledge. My solution to indirect function calls was to implement a set of macros that creates a branch instruction in low memory for each far function and then references those low memory branch instructions for indirect calls instead of the far function. Implementing this strategy directly in the compiler would have been better, but again I don't know much about gcc internals. Robert JMGross wrote: > > > 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 > > -- View this message in context: http://old.nabble.com/suggestion%3A-MSP430X-far-address-warning-tp27397125p27409566.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
