Hi Roman,
Nice to hear that some progress has been made. But I think the whole thing has been addressed from the wrong side. Rather than trying to make the copiler smart enough to decide what to do, or to add switches and whatever, it would have been smarter to return to something that has already been there in the old PC days in the C++ language: the 'far' qualifyer. Back then it was indicating that something is not located in the local 16 bit addressable code or data segment but rather somewhere outside the 16 bit address area. On the MSP, adding a far qualifyer to a data type could indicate that its address is not 16 bit addressable and must be passed as 32 bit pointer (if a parameter) or accessed using the 'A' assembly codes. It also puts any constant into the FARTEXT segment. Giving any far parameter to a function that does not have its parameters defined as far will trigger a 'conversion will lose significant digits' warning or even a type mismatch error. So let the programmer decide where to puthis data. He knows his project best. Same for the functions. A Function with a far qualifyer will cause 1) all functions calling it to use CALLA command, will 2) have a RETA return code, will be 3) compiled as a single compilation unit (so it can be put into TEXT or FARTEXT segment as desired by the linker) and 4) may not call a function which does not have a far qualifyer too. (So all functions without far qualifyer can call each other with the faster and smaller CALL instruction and will have the faster RET instruction). This way, it is obvious what the compiler has to do. Everything whioch might be ambiguous and cause probelms will generate an error or at least warning message. Only the linker needs to have some extra code to allow filling the TEXT segments optionally with far functions and far data if the FARTEXT segment is already full. If such a mechanism not already exists. It will also allow the linker to safely decide which library functions to link, either normal or FAR versions, depending on what is required/used. So it is not necessary to link different libraries depending on memory model but different versions of a function, depending on the usage. To avoid name confusion, the compiler can add a 'FAR_' prefix internally to the function names, so the linker won't have problems to identify the proper ones. And of course the printf format string requires a 'far' qualifyer for its pointer type arguments too, as addition to the already existing long qualifyer etc. It's always faster to tell the compiler what I want than to debug why it doesn't do what I expect. :) JMGross ----- Ursprüngliche Nachricht ----- Von: Roman Lim An: [email protected] Gesendet am: 12.Januar.2010 15:05:40 Betreff: Re: [Mspgcc-users] section .text will not fit in region text > AFAIK the far attribute is just an alias for the segment FARTEXT attribut= e. So the compiler will not solve any of the above problems other than just= placing the code in the FARTEXT segment and generating 430X = > entry/exit code and calls. That's not enough if you don't exactly know wh= at you're doing. But maybe the MSP430X branch has made some progress that w= asn't discussed here (or I missed it). when I first used the MSP430X branch, I also observed some severe problems with jumptables and functions with parameters on the stack. But these are resolved by now. Of course it would be a fine thing if the compiler would be able to place the functions autonomously in NEAR/FARTEXT dependent on type of function (interrupt, normal) and free memory available. Roman
