I'm not convinced that presence of a single far pointer requires that every address kick up to 32 bits. If near/far is maintained as an attribute on the symbol, as apparently IAR uses a __data20 qualifier, it should be possible to manage things properly. Whether GCC+binutils makes it reasonably easy to do this, I don't know yet, but it's certainly not a new problem.
If a function address is qualified as near/far, adapting the CALL instruction to the right form at the time the executable is generated should be straightforward. Some email from Dmitry Diky to the binutils reflector back in the mid 2000s when MSP430X was first added implied the linker (as opposed to assembler) was already handling that sort of thing in some cases where PCREL jump instructions were selected based on the size of intervening instructions. Locating and updating the corresponding RET may be a bit trickier, though again this isn't a problem that only applies to the MSP430. Maybe this isn't doable, but I think it's worth putting some serious effort into trying. If putting printf format strings in far memory means doubling the size of every address in my application, I'm not sure I'm going to want to enable that "feature". But for those who need it, the fallback will be distinct near and far models for code and data, independently, as currently done in the MSP430X branch. (BTW: Anybody know how to get ahold of Dmitry Diky? He's officially the maintainer of binutils for msp430, though I haven't been able to contact him at any known address and haven't seen anything from him in the archives since maybe 2006.) Peter On Wed, Aug 11, 2010 at 7:01 AM, JMGross <msp...@grossibaer.de> wrote: > > Von: Michiel Konstapel > Gesendet am: 10 Aug 2010 14:40:06 > > >> 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" :) > > Some do, some don't. Indeed, if you NEED the space, then you need it. > My experience at e2e.ti.com is that many only think they need it while > they actually need petter programming skills and more imagination :) > > >> 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). > > The problem is that it affects code. If you use a single 20 bit > pointer, then all code in the whole project needs to be written > to support 20 it pointers. As it needs to save the registers as 32 > bit on stack, (including ISRs), needs to deal with stack parameters > differently etc. > > > For bulk data, you can fall back to a manual loading routine. > > that's what I do with my dynamically loaded firmware update and for > some constants. A hand-crafted 'getter' and 'setter' method. > Those who are already using C++ objects won't notice the > difference or the overhead :) > > > 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. > > Yes, it's a rather complex task > > >>>*) 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. > > But it is necessary to note the usage of these flags in the object file. > You may not mix code compiled with or without a flag. It will result in > erratric program behaviour. > > > >> 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? > > yes. > > > 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? > > Basically yes. 20bit program code needs to be called with 20bit > CALLA instruction, but the calling function and all surroundings may > be 16 bit completely except for the function call itself. > ISRs work transparent (the missing 4 bits are automatically saved > in an unused area of the status word) > > A problem are all library functions which take (callback) function > pointers. As the pointers (and pointer variables) are 16 bit. > If these functions use a long value and deal with it properly, > things should work independently of the data model. > Main candidate is printf. > > Once 20 bit data pointers are used, almost all code needs > to take care of it. At least all ISRs and any > code that is called below the first point where these are > used. > > Imagine an ISR that clears the upper 4 bits of your library > functions local data, right in the middle of execution... > Hence the need of a 'data model compatibility flag' in the object file. > > Perhaps this can be emulated by using different code segments for > code using 16 or 20 bit data, and the linker script ensures that only > one of them is populated... > > JMGross > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >
