Hello again, I've been working with the mdata-64k option and so far it has been working flawlessly. Once I got the linux compiler working I tried to build the windows compiler, and I haven't been able to use sprintf from windows (same behaviour as before). Is there anything I can do to narrow down the reason of the problem? Thank you
2009/12/1 JMGross <[email protected]>: > > Ah! > > you switched from the main MSPGCC branch to the 430X branch. This is the > missing link. > When you mentioned older versions of the compiler where it worked, I assumed > that you 'just' used a newer build, not a new architecture. > > An assembly code snippet of the compiled function call would have made this > obvious (push.a instead of push.w instructions etc.). > > So when the compiler puts a 32bit pointer to the destination buffer on stack > and the function assumes 16 bit, then the second 16 bit would be interpreted > as length and the length as pointer to the data. Which leads to > address 0x0100 where chances are that it is a zero value (="empty string"). > So much for the 'save' sprintf version :) > Luckily, in C the caller cleans up the stack after the call, not the callee. > > Looks like we need a lib with separate (sn)printf and far_(sn)printf > functions for the 430X branch. And we need to differentiate between far and > near pointers as two (incompatible?) separate types, not just a different > segment info. Calling a function expecting a far pointer parameter with a > near pointer just does a 16-bit extension, the opposite gives a 'conversion > loses significant digits' warning. > And the printf control string specification requires a 'far' qualifyer for > pointers and strings too. > > Reminds me of the ATMega128 with its 64k data and 128K program space. And > separate '_P' functions if the passed 16 bit pointers point into (word > oriented) program space and not (byte oriented) data space. > > JMGross > > "there's nothing as complicated as a simple pointer - except my wife" (myself) > > ----- Ursprüngliche Nachricht ----- > Von: Jordi Soucheiron > An: GCC for MSP430 - http://mspgcc.sf.net > Gesendet am: 01 Dez 2009 10:03:02 > Betreff: Re: [Mspgcc-users] Problem with sprintf and snprintf in amsp430x2617 > > Michiel, > -mdata-64k worked :D. > Thanks a lot > > 2009/12/1 Michiel Konstapel <[email protected]>: >> I noticed a similar problem with printf (outputting to the UART) with the >> MSP430X branch. Adding -mdata-64k to CFLAGS fixed it for me, maybe it'll >> work for you as well. I'm guessing it doesn't know > how to handle the new 20 bit pointers? > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > -- Jordi Soucheiron Software Engineer DEXMA Parc Tecnològic la Salle Sant Joan de la Salle, 42 08022 Barcelona t/f: [+34] 93 181 01 95 www.dexmatech.com [email protected]
