[Simh] CMP R3,(R3)+

Timothe Litt litt at ieee.org
Mon Jul 30 09:51:17 EDT 2018


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180730/789f800b/attachment.html>


More information about the Simh mailing list