On 30-Jul-18 09:30, Paul Koning wrote: > Yes, that is the standard way to do this. I have never seen the code you > quoted before and I can't imagine any reason for doing that. A memory address test's verification pass. Check that memory contains address of self. Of course, you need a
bne fail following the compare :-) > Either option of course only works if R3 contains a valid memory address, and > it must be even. I should have noted that "valid memory address" includes "even" for words. But if the code provided works on any 11 (obviously, not the 11/20), that constraint is met. > A short way to increment by 2 that doesn't depend on R3 being even would be > CMPB (R3)+,(R3)+. > > It's fairly common to see the TST, not just because it's shorter, but also > because it has a well known effect on the C condition code (it clears it). > For example, a common pattern when C is used to indicate success/fail in a > subroutine: > > TST (PC)+ ; Indicate success > fail: SEC > MOV (SP)+,R1 ; ... > RTS PC > > You might also see code that pops a no longer needed value from the stack, > either clearing or setting C or leaving it alone. To clear, you'd see TST > (SP)+. To set, COM (SP)+. To leave it untouched, INC (SP)+. (More obscure > is NEG, which sets C if the operand is non-zero and clears it if it is zero.) > The C bit was a very common way of returning success/failure from subroutines and system services. In his case, however, the condition codes were ignored in all paths from the instruction. It was just a very odd way of adding 2. Those constructs bring back memories... particularly of debugging such clever code that didn't have the corresponding comment. I often worked on several machines with slightly different ideas of condition codes; switching took some effort. Clever coding is fine - as long as you document it. BLISS got pretty good at being clever - but never at commenting its assembler code. Some of its contortions caused CPU architects to pause before agreeing that the code should work. On a few occasions, SHOULD and DID diverged...
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
