the PC register Puzzle??????????? With SXSim & DEBug
SamMishal
Posts: 468
Mr. Gunther,
I am wondering...... The manual says that the PC register is actually a 9 bit register,
BUT in the SXSim (and IDE Debug) the PC register is showing only 2 digit hex which is 8 bits,
what is happening here when PC should be for example $300 (0011 0000 0000)?
Now the MostSig 3 bits 001 are stored in the Status register but the next bit 1 is nowhere
to be acounted for!!!????
Also I have a puzzle.......See this code:
======================================
·LIST Q = 37
·DEVICE· SX28L, TURBO, STACKX, OSCHS2
·IRC_CAL IRC_FAST
·FREQ·50_000_000
·RESET·· _Main
····· ·org $1FE
_Main
····· jmp @Main
···· Org $200
Main
···· mov··· w,#$01
···· call···· @subtest
···· mov··· $08,w
···· mov··· $08,w
···· jmp ··· $
····
··· Org·$600
SUbTest
·· ·mov···· $08,w
··· mov···· $08,w
··· mov···· w,#10
····ret
END·;End of program code
==========================================================
This code causes the DEbug to go to neverland after the execution of the JMP $ line
and causes an error dialogue on the SXSim. This is obviously due to use of
RET instead of RETP and thus the STATUS register is not restored and therefore
when JMP $ is executed the Jump is made to a bad address (not as intended the current line).
What I am puzzled about is this :
How does the RET instruction cause the execution to go back to the line right after
the Call @SubTest????????
If the RET only pops the PC off the stack and the Page is not restored, HOW???
does the execution go back to the correct page????????
It only fails on the JMP instruction due to wrong Page, but WHY does
the execution resume on the correct page even though the SATUS register still shows
the wrong page.
Is there some shadow register that is actually used upon RET instead of the STATUS for the
Top 3 three bits?
As a side the RETW instruction also does not restore the Status register. IE RETW behaves
exactly like RET (not RETP) but with the added action of moving a constant into the W register.
Regards
Samuel
I am wondering...... The manual says that the PC register is actually a 9 bit register,
BUT in the SXSim (and IDE Debug) the PC register is showing only 2 digit hex which is 8 bits,
what is happening here when PC should be for example $300 (0011 0000 0000)?
Now the MostSig 3 bits 001 are stored in the Status register but the next bit 1 is nowhere
to be acounted for!!!????
Also I have a puzzle.......See this code:
======================================
·LIST Q = 37
·DEVICE· SX28L, TURBO, STACKX, OSCHS2
·IRC_CAL IRC_FAST
·FREQ·50_000_000
·RESET·· _Main
····· ·org $1FE
_Main
····· jmp @Main
···· Org $200
Main
···· mov··· w,#$01
···· call···· @subtest
···· mov··· $08,w
···· mov··· $08,w
···· jmp ··· $
····
··· Org·$600
SUbTest
·· ·mov···· $08,w
··· mov···· $08,w
··· mov···· w,#10
····ret
END·;End of program code
==========================================================
This code causes the DEbug to go to neverland after the execution of the JMP $ line
and causes an error dialogue on the SXSim. This is obviously due to use of
RET instead of RETP and thus the STATUS register is not restored and therefore
when JMP $ is executed the Jump is made to a bad address (not as intended the current line).
What I am puzzled about is this :
How does the RET instruction cause the execution to go back to the line right after
the Call @SubTest????????
If the RET only pops the PC off the stack and the Page is not restored, HOW???
does the execution go back to the correct page????????
It only fails on the JMP instruction due to wrong Page, but WHY does
the execution resume on the correct page even though the SATUS register still shows
the wrong page.
Is there some shadow register that is actually used upon RET instead of the STATUS for the
Top 3 three bits?
As a side the RETW instruction also does not restore the Status register. IE RETW behaves
exactly like RET (not RETP) but with the added action of moving a constant into the W register.
Regards
Samuel
Comments
You definitely are digging deep into the bowels of the SX......good for you!
The call stack has 8 levels and is 11 (12 for SX48/52) bits wide, catching the full 11 (or 12) bit complement of the PC, and hence a RETURN, whether it is RET, RETP or RETW, will return to the proper spot int the program. There are no special shadow registers for the 3 RETURN instructions, all is contained in the call stack. Only RETP adjusts the page bits of the STATUS register to the current page, but of course they may not have been changed in the called routine, and hence may remain (correct) from what they were before.
The JMP instruction is a little different; it only has an 9 bit argument in the instruction label, and pulls the other 2 bits (3 for SX48/52) from the STATUS register. So within the same page, a JMP can go to anywhere of 512 locations, but to go outside that range, the STATUS page bits must first be pre-set, usually through a PAGE instruction.
When doing a "calculated" jump where one's program writes a value to the PC, only 8 bits of the PC are accessible, and the 9th bit is always cleared, hence such a jump can only move within the lower 256 locations of the page. Also, the 10th and 11th (and 12th for the SX48/52) bits are drawn from the STATUS register. Again the desired page must be pre-set.
This same procedure holds for a CALL instruction.
Hope this helps clear things up for you.
Cheers,
Peter (pjv)
see my post in the other thread concerning this topic - this - and especially Peter's explanations in differnt words should help to understand the mysterious program counter issue.
BTW, I don't think that the manual (which one ?) says the PC register is actually 9 bits wide. As mentioned in my other post, the address part of a JMP instruction is 9 bits wide but not the PC register (the one of a CALL is 8 bits wide only).
The RET instructions do not pop off the stack the 8 bit wide PC register mapped into variable space but the full internal (11 or 12 bit wide) program counter. This is why each kind of RET instruction always returns to the correct location in program memory to be executed next, but only RETP also restores the page bits in STATUS that might be required for correct execution of JMP or CALL instructions following.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
The above really makes it a lot clearer.
I was wrong the PC register ($02) is in fact 8 bits but as Mr. Gunther explained (thanks) the actual PC
which the SX uses is 11/12 bits wide. I also now understand that the Stack is also 11/12 bits wide.
But I still would like to know why is it that the actual PC counter as well as register $02 are not displayed.
It would be great to see the contents of both during debugging using either SXSim or the IDE Debug.
I know I sound a little picky but looking at the STATUS (upper three bits) and PC ($02) still would be misleading
in two ways:
·· -The upper three bits of the Status register·together with the PC ($02) register are not
···· sufficient to reflect the actual Programme Counter since the 9th (#8 if you are counting from 0)
···· is still missing.
·
·· -Secondly, if the real PC (not $02) is poped off the 11/12 bit stack and as we see above
···· the upper three bits of STATUS are not always updated
···· then it would be useless to look at STATUS and PC($02) to figure out the actual PC
So I would really like to see an additional field on SXSim and the IDE Debug showing the real PC
in addition to PC($02) and STATUS($03).
Please Mr. Gunther can you do that in the next update!!!!! PLEASE
Samuel
····
Post Edited (SamMishal) : 1/14/2006 8:22:10 PM GMT
I have added the display of the internal SX program counter to the SXSim TODO list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Sam
in the meantime, I deleted this item from my TODO list again - why? Because it is reality now. It will be available with the next update. Before posting a nex update, I usually wait until several items on the list are checked, and until I could do some tests. Therefore, please be patient - it will take a while because I'm almost "over-loaded" with business work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G