The fix I mentioned is based on the fact that multiplication above 16x16 bit (those are inline and work well, since the 32bit HWM is backwards compatible to the 16bit and the inline code is compiled with the current header definitions) is done using some multiplication fucntions linked-in from the gcclib. This lib is already compiled and uses a wrong base address. Also, it just uses the 16x16 multiply to do 32x32 bit and does 64x64 bit in software. Luckily these functions are declared weak. This means you can just include your own version in your source code and the functions in gcclib are ignored. Note that the parameter calling conventions of these functions are NOT following the normal GCC function calling conventions. I guess it is to speed-up this really frequent call. So you'll need to hand-write them with inline-assembly. Some time ago I posted my own versions of these functions to be included into the project source code. These functions are named __umulsi3hw and __umuldi3. They use 32x32 bit hardware for both, 32 and 64 bit multiplication. And of course do not care for any compiler flags but always use the 32 bit multiplier.
Due to a limitation of the C language, it might be better to write your own multiplication functions. If you do a 16x16 multiplication and want a 32 bit result (a common case), C does a 16x16 multiplication with 16 bit result. If you need a 32 bit result, you'll have to typecast one of the values to long. The compiler then extends both values to 32 bit and does an (unnecessary) 32x32 multiplication. If you write your own function, you can just do a 16x16 multiplication and keep the whole 32 bit of the result. Same is true for a 32x32 multiplication with 64bit result. Of course the gcclib needs to be fixed (I wonder it hasn't already for the newer compiler builds). But it is growing more and more complex (with or without 16 or 32 bit multiplier, far and near (non-X) versions etc.). Each new variant doubles the number of required gcclib versions. I think it's better to implement the functionality into the compiler itself, having a single GCClib with all possible function variants and the compiler just compiles the call that is necessary depending on its current compilation settings. If done in separate compilation units, the linker will only link the functions really needed. JMGross p.s.: of course you can apply a patch to gcclib and recompile it. But for the non-X 323 build there is none afaik. ----- Ursprüngliche Nachricht ----- Von: Anthony Asterisk An: [email protected] Gesendet am: 28 Apr 2010 00:54:56 Betreff: Re: [Mspgcc-users] support for msp430F5437 SO how do I fix the 32-bit multiplication functions in gcclib. I think some instructions were sent to the list before I joined. I have no idea what to search for... JMGross wrote: > The MSPGCC build from 12/08 already knows wo these 6 processors. I use it for > some time now. > This build, however, does not have support for the 430X language extension, > so only the first 40K of flash are usable. > There are brances of the MSPGCC wich support the 430X architecture, even > based on GCC4.0 instead of 3.23, but these are still udner development and > unless you want to experiment or even contribute to the compiler > development, I don't really recommend them. (This might change soon as the > development seems to make progress) > > As long as you use the 54xx devices rather for their improved hardware > modules than for the additional flash, the older compiler from 12/08 does its > job. > Then the 5418/5419 are a really good choice and siginficantly cheaper than > the 5438 type. > > You'l need, however, to download the vastly improved header files from the > sourceforge CVS repository. Many additions have been mader after this > compiler release. > And, you'll need to fix the 32 bit multiplication function in gcclib, as it > addresses the hardware multiplyer at the wrong address (you can fix this by > including your own version in your project source code, I postet the code > some weeks ago in this list) > > JMGross
