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
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?