Hi Michiel, it's not a bad idea on first glance. And indeed the easiest solution apart from always doing everything far.
But ... 20 bit pointers are non-standard. They fit into an X-register (other than SR!), but require 32 bit if pushed on stack or stored to memory. But when read from memory, they require only one register isntead of 2 for 'normal' 32 bit values. So this is a source of confusion and possible bugs that might remain undetected for some time. Making a chameleon like a 20bit value the default will open the door for many problems. Always treating them as 32 bit wastes memory and performance but would eliminate possible problems (the programmer cannot make anything wrong and the compiler can handle the cases where a 32 bit value is used for addressing). Unfortunately it would massively increase the register space requirements wherever pointers are used or passed. Making 20 bit the default will however cause problems when it comes to pointer arithmetics (other than the compiler-created one). The programmer will often never notice what's going wrong without a debugger (and we know about the debugging problems with the X devices) So manually and intentionally activating the X features for variables, pointers and functions by declaring them FAR (and using 16 bit if not) is the most transparent way (for the programmer) to handle things. By adding the FAR qualifier, the programmer has actively declared it non-conforming to the 'normal' 16/32 bit world. And the compiler can issue warnings due to type-checking and some simple rules. Everything else is up to the programmer. I'd say there is no 'perfect' solution to this dilemma. The question is what would be the optimum. In any case, the chosen path and its inner workings should be _very_ well documented. JMGross p.s.: actually I don't use nor require any of the X functions right now. The lower 64k is enough for all of my projects right now. I use the 54xx mainly because of its hardware modules and the huge RAM size. And with the current stte of the compiler, my first use of the FARTEXT would be placing some constant tables and the init data for the variables there. ----- Ursprüngliche Nachricht ----- Von: Michiel Konstapel An: [email protected] Gesendet am: 02 Feb 2010 13:09:26 Betreff: Re: [Mspgcc-users] suggestion: MSP430X far address warning > It all depends on your project, and putting everything into 20 bit is > the worst solution of all. Albeit the easiest. I must say that, as a default, the easiest actually sounds best to me. How about doing it the other way around, using NEAR to mark those critical bits where you want the extra speed 16 bit points will give you, but by default, everything is compiled so that it can be linked anywhere and will Just Work (TM)? Michiel ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
