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

error in execution

in the below code mov A,80h does not work correctly.There seems to be 0FFh in 80h but
mov A,80h makes A=0;

        MOV     P0,#00H  ; P0=0
        MOV     P1,#01H  ;      P1=1
PLOOP1:
;       CALL    DELAY

PLOOP2:
        MOV     A,P1
        CJNE    A,#0,PLOOP2
PLOOP3:
        MOV     A,P1
        CJNE    A,#1,PLOOP3

        MOV     A,80H
        MOV     A,0A0H
        MOV     A,0A1H
        MOV     A,0A2H
        MOV     A,0A3H
        MOV     A,P0
        CPL     A
        MOV     P0,A
        JMP     PLOOP1

Parents
  • I want assembly equivalent of the following code

    What for? You have a rather nicely working compiler to turn that C code directly into machine code. So what, other than a homework task, could possibly possess you to think you need this code in assembly?

    ; 80H contains 0FFh but this line makes A=0
    

    And you know that ... how? Are you aware there are no less than 5 addresses "80H" in you 8051? Do you recognize what this particular adress 80H is? The fact you didn't call it by its usual name rather strongly indicates you don't.

    And what exactly did you consider "very clear" about a sequence of 4 reads into the accumulator that does nothing with any of the values being read, without any semblance of an explanation what that's supposed to do?

Reply
  • I want assembly equivalent of the following code

    What for? You have a rather nicely working compiler to turn that C code directly into machine code. So what, other than a homework task, could possibly possess you to think you need this code in assembly?

    ; 80H contains 0FFh but this line makes A=0
    

    And you know that ... how? Are you aware there are no less than 5 addresses "80H" in you 8051? Do you recognize what this particular adress 80H is? The fact you didn't call it by its usual name rather strongly indicates you don't.

    And what exactly did you consider "very clear" about a sequence of 4 reads into the accumulator that does nothing with any of the values being read, without any semblance of an explanation what that's supposed to do?

Children
  • Yes, lots of people think their problem is caused by a compiler bug, because if it is a compiler bug then it is someone elses fault.

    By the way - exactly how would the compiler even be involved in this?

    And didn't you get enough of a hint from Hans-Bernhards answer to think a bit more about the problem? Exactly what does that source line mean?

  • I do assume you're using an 8051 derivative with at least standard address of Port 0.

    So first you write a value 0 to Port0 in line: MOV P0,#00H ; P0=0

    The you wonder why it is still 0 when you read it back in: MOV A,80H

    I think the problem is not in the computer, but in front of it.

    Hans-Bernhard Broeker has already asked you to explain what makes
    you think that "80H" contains 0FFh. Do you mean C:0x80, or X:0x80
    or I:0x80, or D:0x80, or B:0x80?

    best regards

  • I run the same code in the EdSim and it works correctly therefore I think it is a compiler bug
    80h is D:0x80 which is P0 at the same time
    At the beginning P0=0,after making p1=0 and p1=1 using memory watch I get out of the loops(ploop1 and ploop2 respectively) and the value of 80h becomes 0FFh.But when running the loops second time and finishing them by making p1=0 and p1=1 using memory watch it should be read as 0FFh into the A. Instead it is read as 00h

            MOV     P0,#00H  ; P0=0
            MOV     P1,#01H  ;      P1=1
    PLOOP1:
    ;       CALL    DELAY
    
    PLOOP2:
            MOV     A,P1
            CJNE    A,#0,PLOOP2 ; loop until P1=0
    ; here I enter data 0 into the Port1 using
    ; memory watch to end the loop
    PLOOP3:
            MOV     A,P1
            CJNE    A,#1,PLOOP3 ; loop until P1=1
    ; here I enter data 1 into the Port1 using
    ; memory watch to end the loop
    
            MOV     A,80H ; here is where the problem occurs
    ; 80H contains 0FFh but this line makes A=0
    ; other lines work correctly
    ; moreover I run the same code snippet with EdSim and it works correctly
    ;        MOV     A,P0
            CPL     A
            MOV     P0,A
            JMP     PLOOP1
    
    

  • "...therefore I think it is a compiler bug..."

    What compiler are you talking about?

    You've got some (rather poorly written) assembler and you're describing what a simulator is reporting.

  • And how would the compiler be involved in what the simulator decides to read back from port pins?

    And what does P1 have to do with the contents read back on P0?

    Don't you think the biggest issue when _you_ get into troubles with a simulator is that _you_ have made assumptions that just are not true?

    But since you are a very experienced developer - you would have to be to make claims that the compiler has a bug - you would probably have a good understanding of the ports on the 8051 chip. What is the "normal" values to write to P0 if you want to use P0 as an input? What is the meaning of writing 0 to P0 and then trying to use P0 as an input?

    Would you care to describe to us the logic behind your code. What _you_ think happens, and if what you do seems consistent with what "all other" code out there seems to do.

  • I STRONGLY suggest you get out either "the bible" or the datasheet for your processor and read up on what makes P0 different from P1-3

    Also, why address 80h when there is a perfectly good name for it?

    Erik

  • It might possibly be a school assignment - to analyze a program and figure out what it _actually_ does or does not do. Just to prove some understanding of the processor.

  • I run the same code in the EdSim and it works correctly therefore I think it is a compiler bug

    That logic has holes in it that one could throw a truck through.

    ; 80H contains 0FFh but this line makes A=0
    

    You've been repeating that claim about half a dozen times by now, and been challenged about it more often than that. Don't you think it might be time to finally begin investigating it's correctness in earnest, instead of repeating the same nonsense over and over?

  • I run the same code in the EdSim and it works correctly therefore I think it is a compiler bug