This code is using the hardware multiplier, available on some msp430 cores (like the msp430f14x). The hw multiplier is a peripheral, residing at addresses around 0x13x. To use it, the two sources are written to the source addresses, then the result can be read out - the exact addresses used depend on the size of the operands and whether they are signed or unsigned. But since the hw multiplier is a shared resource, the compiler must turn off interrupts while it is in use (in case an interrupt occurs in the middle of the multiply, and uses the hardware multiplier itself). So assuming you are running on an msp with a hardware multiplier, the code in (a) looks correct to me. I also don't see anything wrong with (b).
If it is critical to your code that interrupts are not disabled for the few clock cycles involved here, then your design is probably flawed - unless you have a system with only one possible interrupt source (at a time), since any other interrupt routines will disable interrupts for a lot longer than the hardware multiplier sequence. If you are sure that no interrupt routines use the hardware multiplier, there is a compiler flag (-mhwmul-no-int) to disable the push R2 / dint / pop R2 sequence, which will make the multiply code a little smaller and faster. Remember that other code, such as array index calculations, could use the hardware multiplier, so if you are using this flag it may make sense to compile modules containing interrupt code with the flag (-mdisable-hwmul) that disables the hardware multiplier entirely. Politeness note - generated code is not "bogus" just because you don't know what it does, or why it is there. It is "unexpected", or "confusing" - it is not "bogus" or "wrong" until there is no doubt about it, which generally means one of the real experts (I would describe myself as an "advanced user", rather than an "expert") on this list should confirm it. Hope that helps, David. > Greetings, > This is using the release 1 of the compiler. > We are having problems with a bogus code insertion when calling some > functions particularly when calling the integer multiply or division > library functions. > It apppears to have inserted a bogus function instead of a call to the > multiply function. In all cases, the compiler is disabling interrupts (this > is really bad for this project) while it refreshes R15 with 0x013a, and > then re-enables ints. Why does it disable interrupts, and what is it trying > to do the 0x13a? The calculation is incorrect as a result of this > dint/push/pop r15 operation as there is no multiplication. The <__mulhi3> > library function is missing from the list file. > Here are two examples from the list file of reused code in two projects, > the first is compiled with release 1 (2002-12-17) , the second was compiled > with (2002-09-22). Release 1 appears to completely miss out on doing the > multiply, and inserts the bogus dint/push/R15 manipulation/pop. Anywhere we > have done an integer muliplication and division in release 1, the resultant > assembly code structure is the same. > I would appreciate some clues/comments/help?? > > Example (a) > x = (SWORD)(input - pBuf[index].c); > c60a: 4f 4b mov.b r11, r15 ; > c60c: 0e 4f mov r15, r14 ; > c60e: 0e 5e rla r14 ; > c610: 0e 5f add r15, r14 ; > c612: 0e 5e rla r14 ; > c614: 0e 59 add r9, r14 ; > c616: 1a 8e 04 00 sub 4(r14), r10 ; > x *= (SWORD)(-pBuf[index].inv_m); > c61a: 5f 4e 02 00 mov.b 2(r14), r15 ; > c61e: 3f e3 inv r15 ; > c620: 1f 53 inc r15 ; > c622: 02 12 push r2 ; > c624: 32 c2 dint > c626: 03 43 nop > c628: 82 4a 32 01 mov r10, &0x0132 ; > c62c: 82 4f 38 01 mov r15, &0x0138 ; > c630: 1f 42 3a 01 mov &0x013a,r15 ;src addr 0x013a > c634: 32 41 pop SR ; > x /= (SWORD)(pBuf[index].scale); > c636: 5e 4e 03 00 mov.b 3(r14), r14 ; > c63a: 0c 4f mov r15, r12 ; > c63c: 0a 4e mov r14, r10 ; > c63e: b0 12 1e c9 call #-14050 ;#0xc91e > c642: 0f 4c mov r12, r15 ; > > 0000c91e <__divmodhi4>: > > Example (b) > x = (SWORD)input - pBuf[index].c; > ed28: 4d 4a mov.b r10, r13 ; > ed2a: 4e 4b mov.b r11, r14 ; > ed2c: 0f 4e mov r14, r15 ; > ed2e: 0f 5f rla r15 ; > ed30: 0f 5e add r14, r15 ; > ed32: 0f 5f rla r15 ; > ed34: 0f 59 add r9, r15 ; > ed36: 1d 8f 04 00 sub 4(r15), r13 ; > x *= (SWORD)pBuf[index].inv_m; > ed3a: 5e 4f 01 00 mov.b 1(r15), r14 ; > ed3e: 8e 11 sxt r14 ; > ed40: 0a 4d mov r13, r10 ; > ed42: 0c 4e mov r14, r12 ; > ed44: b0 12 8e f8 call #-1906 ;#0xf88e > x /= (SWORD)pBuf[index].scale; > ed48: 5f 4f 02 00 mov.b 2(r15), r15 ; > ed4c: 0c 4e mov r14, r12 ; > ed4e: 0a 4f mov r15, r10 ; > ed50: b0 12 dc f8 call #-1828 ;#0xf8dc > ed54: 0f 4c mov r12, r15 ; > > 0000f88e <__mulhi3>: > 0000f8dc <__divmodhi4>: > > > Phil Hancock > Australia > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > >
