I suggest replacing the intrinsic functions by macros or inline-functions with 
hand-crafted inline assembly code.
This way, you have full control over the generated assembly code and it can be 
written as small as possible.
e.g. the delay function: take the parameter, shift it right by 3 bits and 
generate a loop that takes exactly 8 cycles.
Generates only a few bytes code , and gives an exact result. (unless an ISR is 
intercepting).
Using a function would be inefficient, not for the funciton call overhead 
(which can be calculated and subtracted), but for the preparation of the 
function call (mving the parameter to r15) and clobbering r12-r15 -> larger 
code in the calling fucntion for about 4 saved bytes per call.
If you have access to IAR, you can even look into the debugger for the 
generated code for these intrinsics and copy it.

While mspgcc does many sophisticated optimisations, I found that sometimes 
these optimisations can be easily optimized even more. There are unnecesssary 
register moves and similar thing left. Maybe a second 
optimisation pass could do some good :)
So if you have to do something tight, use inline assembly. These intrinsics are 
good candidates for doing so.

JMGross

----- Ursprüngliche Nachricht -----
Von: Paul F. Sehorne
An: Richard Newman; GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 04 Jun 2010 05:09:13
Betreff: Re: [Mspgcc-users] mspgcc linking problems porting TI Sports Code to   
mspgcc


I have completed the port to mspgcc except for the following items:
The last linking hurdle, the "warning: internal error: unsupported 
relocation error", remains.  This is caused by a bug in mspgcc4.  The 
bug has been fixed but has not been integrated into the mainstream 
mspgcc4 code.
It was necessary to use -Os to get the code size down to the 32Kb flash 
size of the MSP430F6137 - even after eliminating all bluerobin code.
I have not implemented the intrinsic function __delay_cycles
None of the four  intrinsic functions have been tested - due to the 
linking problem.  My first pass as these was just dummy functions to get 
past the compile errors and move on to linking.  I wanted to get through 
the complete build procedure - compiling and linking - and then come 
back to the intrinsic functions.  Three of the intrinsic functions have 
been implemented (they are not just dummy code / empty functions, like 
__delay_cycles still is), but as mentioned have not actually been 
tested.  I am getting a clean compile with no errors.
I am getting the compile 'warning' in mspgcc4 signal.h
There are a couple of areas in the code where I used #ifdefined __GNUC__ 
to implement mspgcc specific functionality.  These areas may need 
refinement.


Reply via email to