<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 30-Jul-18 09:30, Paul Koning wrote:<br>
<blockquote type="cite"
cite="mid:9CA47FB8-75DB-4551-A8C6-3CE02B7B3823@comcast.net">
<pre wrap="">
</pre>
<pre wrap="">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.</pre>
</blockquote>
A memory address test's verification pass. Check that memory
contains address of self. Of course, you need a <br>
<br>
bne fail<br>
following the compare :-)<br>
<br>
<blockquote type="cite"
cite="mid:9CA47FB8-75DB-4551-A8C6-3CE02B7B3823@comcast.net">
<pre wrap="">
Either option of course only works if R3 contains a valid memory address, and it must be even. </pre>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:9CA47FB8-75DB-4551-A8C6-3CE02B7B3823@comcast.net">
<pre wrap=""> 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.)
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
<br>
</body>
</html>