> Generally using 20 bit registers isn't advisable as it increases code > size and execution times and only a fraction of the MSP users needs the > additional code size. Many (inlcuding me) just need the higher speed, more ram or > better peripherals.
On the other hand, many (including me) are mainly interested in the extra flash and are happy to take the step BACK in RAM going from a 1611 to a 2418. "It's faster" doesn't help if you're stuck at "but it doesn't fit" :) I know we've discussed this before, but I at least wanted to mention in this context. > And even if so, often putting the functions far is good enough. Constant data, too, would be nice, but I agree with the advantages of sticking to 16 bit data pointers (unless 20 bits are requested by a switch). For bulk data, you can fall back to a manual loading routine. For example, I'm working with some people who run a Java VM on their nodes and they store class files in the upper flash. They'd rather access that data through a regular C pointer, but they currently manage with a bit of assembly. Being able to automatically split code into both low and far memory would be great, but as far as I understand, is fairly impossible for ld. > >*) How much unhappiness would there be if the default compiler behavior was > > to support near-mode compilation, with far-mode for code and/or data as > > an option specified either by attributes in the source or compiler flags? I don't mind which becomes the default, if it's easy to (globally) change. The -mdata-64k and -mcode-64k flags of mspgcc3's MSP430X branch, or their inverse, would do the trick. > So my proposal is: far attribute for functions and constants (automatic > for strings e.g. in printf), but for constants only if enabled with > additional commandline switch. Then the command line switch would select a different, precompiled library with far data pointers? If I understand correctly, the overhead for 20 bit code addresses is localized to the functions that use it (so libraries can be compiled once and will work either near or far), but 20 bit data pointers force that overhead on the whole program? Kind regards, Michiel
