This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C51: 32 bits unsigned returned values treated as signed 16 bits

Hi!

In a full project a simple unsigned long ( u32 )returned value from a function lead to this (odd) assembler code.
It make us think that the u32 is considered as s16 ( signed short ).

If the sub-function th_microSecondsNow() returns the u32 0x0000FFCA the local_us returned will be 0xFFFFFFCA.
If the returned u32 is 0x00120233 the local_us returned will be 0x00000233.

For example the value is well settled in R4 = 00, R5 = 12, R6 = 02, R7 = 33 but at the end
R4 = 00, R5 = 00, R6 = 02, R7 = 33

We tried the same code in an empty project and in this case the function's behaviour is totally normal ( returned local_us values 0x0000FFCA or 0x00120233 ).

Any Ideas of what went wrong?

Many thanks in advance.

//please find below the assembler code abstract

   271: u32 microSecondsNow(void)
   272: {
   273:     u32 local_us;
   274:     local_us = th_microSecondsNow();
C:0x8DCB    1287A5   LCALL    th_microSecondsNow(C:87A5)
C:0x8DCE    EE       MOV      A,R6
C:0x8DCF    33       RLC      A
C:0x8DD0    95E0     SUBB     A,ACC(0xE0)
C:0x8DD2    FD       MOV      R5,A
C:0x8DD3    FC       MOV      R4,A
C:0x8DD4    900D1C   MOV      DPTR,#0x0D1C
C:0x8DD7    121DD0   LCALL    C?LSTXDATA(C:1DD0)
   275:     return local_us;

Parents
  • Naturally during first steps of development the number of warning is huge and this one was completely lost among the others

    I would disagree with the assumption that you might expect a huge number of warnings during the first steps of a developments.

    A sensible approach is to always treat warnings as errors until or unless you can prove otherwise.

Reply
  • Naturally during first steps of development the number of warning is huge and this one was completely lost among the others

    I would disagree with the assumption that you might expect a huge number of warnings during the first steps of a developments.

    A sensible approach is to always treat warnings as errors until or unless you can prove otherwise.

Children
  • "I would disagree with the assumption that you might expect a huge number of warnings during the first steps of a developments."

    I prefer iterative development, where new code is added, compiled and tested in small blocks. And warnings getting caught and analyzed as they show up. So never any large numbers of warnings. But sometimes a large number of errors, because of some syntax error.

    It's best to take care of any warnings immediately, while the relevant code lines are in fresh memory. And preferably before the code is module-tested, to make sure that a late change doesn't break the code.