Topic : Strange code in library funcion ?C?muls161632

Forum : ST7/STM8

Original Post
Post Information Post
July 6, 2011 - 3:48pm
Guest

I have a line in my program that look like this

int a,b;
long c;

...

c = (long)a*b;

When compiled, the assembler code contain this line

0013 8D000000 F CALLF ?C?muls161632

When I debugged my application I noticed that efter the call to ?C?muls161632 the interrupt level bits in the CC register was suddenly 0. I started to debug the function ?C?muls161632 and found this code

Here is the code for ?C?muls161632 copied from the debugger

0x8081 <?C?muls161632+1> 0x5D TNZW X TNZW X
0x8082 <?C?muls161632+2> 0x2A02 JRPL 0x8086 JRPL 0x8086
0x8084 <?C?muls161632+4> 0x50 NEGW X NEGW X
0x8085 <?C?muls161632+5> 0x43 CPL A CPL A
0x8086 <?C?muls161632+6> 0x905D TNZW Y TNZW Y
0x8088 <?C?muls161632+8> 0x2A03 JRPL 0x808d JRPL 0x808d
0x808a <?C?muls161632+10> 0x9050 NEGW Y NEGW Y
0x808c <?C?muls161632+12> 0x43 CPL A CPL A
0x808d <?C?muls161632+13> 0x88 PUSH A PUSH A
0x808e <?C?muls161632+14> 0x89 PUSHW X PUSHW X
...
0x809d <?C?muls161632+29> 0x88 PUSH A PUSH A
...
0x80a2 <?C?muls161632+34> 0x84 POP A POP A
0x80a3 <?C?muls161632+35> 0x85 POPW X POPW X
...
0x80b4 <?C?muls161632+52> 0x86 POP CC POP CC
...
0x80c8 <?C?muls161632+72> 0x87 RETF RETF

I found a disturbing "POP CC" call as you can see above. In this case, the value on the stack contain the word 0 which mean that the CC register gets the value 0. Can anyone explain this?

Best Regards
Andreas

Replies
Post Information Post
+1
0
-1
July 7, 2011 - 3:26pm
Raisonance Support Team

Wow, bird's eye!

Indeed we confirm this problem. It will be fixed in a future RKit-STM8 release. However, the next version (nearly out) will not integrate the fix, as it is already qualified.

As a temporary fix what you can do is change a or b to long type, which will call the unoptimized 32x32->32 multiplication.
If this is not satisfactory for you please contact and we can provide you with a patch.

Best Regards,