Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1776 [PIC14]unsigned arithmetic problem or code optimalization

open
nobody
PIC14
5
2013-07-16
2011-04-03
Gál Zsolt
No

This is not my day. I stoped again because the compiled code doesn't cover what I wanted in C code. In the attached code you will fine two for(;;) loops which should be working in the same way - I think, but both of them has a side effect. The first where I make multiplication inside the function call give wrong result, when the MSB bit of the result is 1, because it is interpreted as a SIGN of the result, and then there is a correction according it on the HIGH byte of the result and it goes trough the function call.
I tried to avoid the first problem, but I found another. I pulled out the multiplication from the bracket and the result goes into an unsigned int variable. The SIGN correction disappeared, but the HIGH byte of these variable doesn't go trough the function call.
I am confused little bit what am I think wrong.
( I tried it with --no-pcode-opt, but it didn't have affect. )

Discussion

  • Gál Zsolt
    Gál Zsolt
    2011-04-03

    Sample code with comments

     
    Attachments
  • Gál Zsolt
    Gál Zsolt
    2011-04-04

    I made something wrong around --no-pcode-opt, that cause no effect on the result. I have repeated my test and the result is better. The second part of my code is OK in the compiled assembly file with this option. But I don't understand why sdcc is using SIGN correction at the first part of this example.

     
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,4 +1,3 @@
    -
    
     This is not my day. I stoped again because the compiled code doesn't cover what I wanted in C code. In the attached code you will fine two for\(;;\) loops which should be working in the same way - I think, but both of them has a side effect. The first where I make multiplication inside the function call give wrong result, when the MSB bit of the result is 1, because it is interpreted as a SIGN of the result, and then there is a correction according it on the HIGH byte of the result and it goes trough the function call. 
     I tried to avoid the first problem, but I found another. I pulled out the multiplication from the bracket and the result goes into an unsigned int variable. The SIGN correction disappeared, but the HIGH byte of these variable doesn't go trough the function call.
    
    • Category: --> PIC14