assembly traps I need explained
Erik Friesen
Posts: 1,071
In this example why does missed get added to If it immediately follows the (if_nz add missed,#1) regardless of the state of z?
Why in this example could an and or add xor bits 4..7 of the variable? ( note one or so of these may have been commented out I can't recall exactly but it was being xored with some combination)
Or does it have something to do with using a initialized long·to and a variable?· I notice complete different results using an (and code,#%11110000) versus an (and code,clear) on the lower eight bits(with clear being the same number).· It seems like the lower eight would be treated the same to me.· I am scratching my head over this.· Is there a way to read the compiled 32 bit instruction?
cmp count0,#170 wz if_z call #testcode wrlong missed,codep wrlong blo,batlop wrlong bhi,bathip call #delay call #loop 'repeat testcode cmp pcode,code wz if_nz add missed,#1 testcode_ret ret
Why in this example could an and or add xor bits 4..7 of the variable? ( note one or so of these may have been commented out I can't recall exactly but it was being xored with some combination)
mov t1,code shr code,#4 and code,#%1111 shl t1,#4 and t1,clear add code,t1
Or does it have something to do with using a initialized long·to and a variable?· I notice complete different results using an (and code,#%11110000) versus an (and code,clear) on the lower eight bits(with clear being the same number).· It seems like the lower eight would be treated the same to me.· I am scratching my head over this.· Is there a way to read the compiled 32 bit instruction?
Comments
For the second problem you need to provide a proper example where we know what code and clear are.
I'm having trouble understanding what you mean in the second case.
Graham
"and code,#%1111" masks off the lower 4 bits of "code" setting all the other bits to zero.
"and code,#%11110000" masks off the next 4 bits of "code" (bits 4-7).
Make sure that "clear" is what you expect it to be. The instructions work as advertised. Just remember that the immediate field is 9 bits and the 9th bit is not treated as a sign (it is not extended).
The only way to look at the assembled instructions would be to put some kind of known byte pattern in the DAT section and look for that in the hex listing for the program. For example, if your assembly routine starts with the label "entry", you'd have
DAT byte 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 org 0 entry ' 1st instructionI think it's reasonable to assume it's programmer / logic error rather than a faulty chip.
The only way 'missed' would be incrementing is if WZ flag is clear which is whenever 'pcode' does not equal 'code'. Have you perhaps misunderstood the way WZ works ? CMP is a subtract which doesn't store its result will set WZ when the result is zero, ie when 'pcode' equals 'code'.
The other thing is,"call #loop 'repeat" - is that not meant to be a JMP rather than CALL ? That could easily be corrupting code and causing erroneous and unpredictable operation.
There may be other errors in the code, all of which can corrupt the execution code and alter the flow within the program. The increment of 'missed' could be occurring because it's being executed other than immediately after the instruction which precedes it in the source code.