how to handle 16 bits x 16 bits multiplication on c5515 ?

The problem isn't with your macro, it's how the compiler is interpreting it.

As you pointed out there is a 17x17 multiplier and a 40 bit accumulator.  Combined with the barrel shifter, this combination of hardware provides very efficient 16 bit fixed point arithmetic.  The problem is that the official methods defined in the C standard make taking advantage of this hardware a little difficult.

According to the C standard, if you multiply a 16 bit int by another 16 bit int you will get a 16 bit result because the C standard assumes all integral types represent numbers with the implied radix point just to the right of the LSB.  So, your multiply of 0xFF84 by 0x16 would result in a value of 0xF558 and when promoted to a signed type and right shifted by 15 you get 0xFFFF.  Again, this is expected by the C standard.

To effect what you want within the confines of the C standard, each value would need to be promoted to a 32 bit value as in

y = (int)( ( (long) a * (long) b ) >> 15 )

At first glance this is exactly what your macro does.  However, again within the confines of the C standard, this code would require a subroutine call to a 32x32 multiply routine requiring a total of 4 multiplies and 3 additions followed by a right shift and then truncation of the value into a 16 bit int again.

Since the writers of the code gen tools knew that this was expected from the C5xxx processors, they created a special shortcut to accomplish what you want to do without having to call the 32x32 multiplication subroutine.  Thus if you write code that appears to the compiler as

(int)( ( (long) a * (long) b ) >> n )

then it implements a single multiply instruction and shift.  It gives you then intended result when applied properly but, as you have seen, it can fail under certain circumstances.

What is happening in your code is the compiler is recognizing your code as a request to perform this optimization automatically.  Thus the value of 0xFF84, which would normally be interpreted as an unsigned int (because it is a hexadecimal constant) is actually being interpreted as a signed int of -124 because the cast to signed long is not actually accomplished thus the upper 16 bits are effectively interpreted as 0xFFFF instead of 0x0000.  Thus your 40 bit result ends up being 0xFF_FFFF_F558 which when right shifted by 15 yields 0xFF_FFFF_FFFF and when truncated leaves 0xFFFF to be assigned.

There is a solution for this however, but you merely need to recognize the limitation of the compiler implementing the shortcut.  This short cut can work for either signed operands or unsigned operands and you need to make sure you utilize the one you need.  Thus you should have two macros defined as

#define SMULT( a, b, n ) ( (int)( ( (long)(int) a * (long)(int) b ) >> n ) )

#define UMULT( a, b, n ) ( (unsigned int)( ( (unsigned long)(unsigned int) a * (unsigned long)(unsigned int) b ) >> n ) )

Now if you call the UMULT macro as UMULT( 0xFF84, 0x16, 15 ) you will get the answer you are looking for.

The additional casts may seem overkill but it is important to make sure you tell the compiler how to interpret the operand before casting it to the long form.

Also, if the special format gets too complicated due to passing equations to evaluate in the macro or including the macro in a large equation, the compiler may not be able to properly identify the syntax to effect the optimization.  Thus it is suggested that you always use the above macros by themselves, with single variables or constants passed, and assign its result to a variable.  This will help to insure the compiler implements your expected results.

Jim Noxon