Indeed, you're right that fully implementing far pointers as 32 bit is slower than using 20 bit pointers. Unfortunately the 20 bit registers won't fit in the normal compiler workings. Since storing them to memory or stack requires 32 bit storage space (24 won't work well because of the word alignment). Also, arithmetics are difficult on 20 bit. While it makes not much sense to do 20 bit multiplications and divisions, at least addition and subtraction are common and it's not clear what the outcome is: Is the 20 bit pointer extended to 32 bit for a 32 bit addition? Or will the other operand extended to 20 or even 32 bit before the operation? Is the result 32 bit, so it won't fit into a 20 bit register?
Unless we introduce another scalar type such as 'far int', which is 20 bit and between short and long int, things are not that easy. The best way would still be to clean up this mess through types. And here your requested warning will automatically come when the number of effective bits is reduced implicitely by a conversion. Or, the types are not automatically typecasted and you will get an error without a typecast. Serves as well. In any case, some deeper changes in the compilers inner workings are necessary. Unless you go the (IMHO) wrong way and leave it all to the programmer. But then we could as well go back to assembly level. :) About the functions, it is all known to the compiler. The linker will not generate call/calla opcodes. It will just link using 20 bit pointers to calla and 16 bit pointers to call functions. Of course the linker needs to know that not all pointers are 16 bit. But that's not too difficult. As for the functions: all functions NOT declared as FAR con only be called from ohter functions NOT declared as FAR and generate a RET code. All functions declared as FAR generate RETA codes. Also, all FAR functions are called with CALLA (even if linked into TEXT) and all non-FAR function are called with CALL. As addition, calling a non-FAR function from within a FAR function generates an error. That's a very easy set of rules. And the compiler knows at compile time what's up. Same for constants in FLASH: either they are declared FAR and can reside anywhere, accessed with 20 bit pointers, or they are not FAR and are in low memory, being accessed with 16 bit pointers. Same for funciton parameters. If FAR then fine and any non-FAR variable pointer is expanded, if non-FAR, you'll get a warning about lost bits or even an error. Even indirect function calls are known by the compiler, given the function pointers type. Only that you may not indirectly call a near function from a far function, by auto-casting the near address pointer into a far address pointer when assigning to the pointer variable. Here the compiler should as well generate a warning/error. But the compiler already knows here as well what's happening: you take a 16 bit pointer and assign it to a FAR function pointer. Without an explicit typecast (this should still be allowed), an error should be generated. The main reason for keeping the 16 bit pointers is that depending on your program you might not need at all the additional FLASH (and therefore not need any 20 bit stuff) or have just a lot of string constants which are accessed relatively seldom (so they are best in FARTEXT) while the code is small and should be as fast as possible for the calculations. Or you have much code and large tables and you want the tables in TEXT for fast access while the code might reside in FARTEXT if both together grows too large. It all depends on your project, and putting everything into 20 bit is the worst solution of all. Albeit the easiest. JMGross ----- Ursprüngliche Nachricht ----- Von: kavaler An: [email protected] Gesendet am: 01 Feb 2010 20:09:15 Betreff: Re: [Mspgcc-users] suggestion: MSP430X far address warning 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
