On 2007-03-23, Oleg Verych <[email protected]> wrote:
>> From: Grant Edwards
>> Newsgroups: gmane.comp.hardware.texas-instruments.msp430.gcc.user
>> Subject: Question about libgcc 16x16=>32 multiply
>> Date: Thu, 22 Mar 2007 20:23:28 +0000 (UTC)
>
> Hallo.
>
>> uint32_t r;
>>         
>> void foo(uint16_t u1, uint16_t u2)
>>   {
>>     r = (uint32_t)u1 * (uint32_t)u2;
>>   }
>>   
>>
>> I've been looking at the code for the case above:
>>
>>      1       foo:
>>      2               push    r11
>>      3               push    r10
>>      4               mov     r15, r10 
>>      5               mov     r14, r12 
>>      6               clr     r11
>>      7               clr     r13
>>      8               call    #__umulhisi3
>>      9               mov     r14, &_r
>>     10               mov     r15, &_r+2
>>     11               pop     r10
>>     12               pop     r11
>>     13               ret
>>
>>
>> I've noticed that even though a 16x16 multiply is being called,
>
> As i'm new on all this, i just note, that function names are very
> strange.

Huh?

>> the two operands are being passed as 32-bit values.
>
> And this is, what your C expression tells, no?

Yes, but the compiler is smart enough that it has recognized
that it needs to do a 16x16->32 multiply, so it's calling a
16x16->32 multiply:

"umul"  means unsigned multiply.
"hi"    means 16 bit operands
"si"    means 32 bit result
"3"     means result doesn't overwrite either operand

>> Why pass two 32 bit values to a library function who's purpose is to
>> multiply two 16 bit values?  IOW why are lines 6 and 7 there?
>
> file gcc/config/msp430/libgcc.S:
> ...
>         .global __umulhisi3
>         .func   __umulhisi3
> __umulhisi3:
>         br      #__mulsi3
> ...
> /*******************************************************
>                Multiplication  32 x 32
> *******************************************************/
> ...
>         .global __mulsi3
>         .func   __mulsi3
>
> __mulsi3:
>
> Thus, it seems 32x32 instead.

That's because nobody has bothered to write a 16x16->32
multiply routine. For other targets where that's the case,
there either isn't a umulhisi3 function (the compiler does the
16->32 conversion before generating the instuction), or
umulhisi3 expects 16-bit operands and converts them to 32 bit
values before jumping to the 32x32 multiply.

My question is: why does umulhisi3 expect to be passed 32-bit
operands when it's defined as a 16x16 multiply?

-- 
Grant Edwards                   grante             Yow!  I have no actual
                                  at               hairline...
                               visi.com            


Reply via email to