Has Anyone Written PDP-8 .XOR. Code Using the MQ Register (Without the EAE)?

[CLASystems]

On Wed, Dec 23, 2015 at 10:14 PM, Christian Gauger-Cosgrove <
captainkirk359 at gmail.com> wrote:

> On 23 December 2015 at 13:44, CLASystems <clasystems at gmail.com> wrote:
> > Ironically, the shortest and fastest seems to be avoidance of the MQ
> > altogether [thus making it work on ANY model].
> >
> >     TAD  ARGONE
> >     AND  ARGTWO
> >     CLL RAL
> >     CIA
> >     TAD  ARGONE
>
​   ​
>     DCA ARGTWO

​OOPS!  The LAST INSTRUCTION SHOULD BE TAD ARGTWO !

Starts with a clear AC, ends with AC containing argone .xor. argtwo.
Neither  argone nor argtwo are modified.

Sorry, too much transcribing from notes about notes, etc.  :-).

This is a fragment from a larger topic about the TD8E.  If you start with a
CMA in front of the code and a CMA at then end, you have the ARGONE .EQU.
ARGTWO, but that's even longer.

The larger argument is that you need not calculate .equ. every 12 bits
because on a DECtape, you can combine them halfs-wise at the end and then
invert the six-bit result to write on the tape [or compare what you read
from the running calculation as you read it.

Thus, each word loop is two instructions shorter and you can combine if you
are clever in about one extra instruction but 1 or more total cycles less
[for a net gain of one instruction and a little bit of time at the most
critical point and a bit more at the slightly less critical points.

The original discussion is that since the TD8E is for the Omnibus only, why
not see if the MQ can be helpful. It seems not in the end because it takes
even longer ironically [and a few more instructions, etc.]

However, BSW will likely help in that separate "sticky" point to some small
extent.

[The overall topic is beefing up a TD8E in every way possible to make the
real-world tape [not the SIMH] be more free of
tape/cleanliness/guide/wear/tape-wear issues that can make the wost-case
jitter problems come dangerously close to failing.  When all the hardware
and media are new, it's less of a concern..  However, there are actual
systems running the hardware and some predictable problems.  I'm just
pursuing the theoretical [and practical] software issues, etc.  [Can't go
up one "level" in why just yet; a few already know why, but that's all I am
prepared to say for now.]

cjl [I found one of my own posts on-line from back in the day, and was
trying to pursue it.]​


>
> > This works because .XOR. is addition ignoring the carry bits.  So,
> knowing
> > they will happen, just allow them at first, then remove them.
> >
> Hmm, I just tried that in SIMH, and that doesn't XOR at all. I haven't
> a clue what it does.
>
> What I have entered:
> sim> ie -m 100-105
> 100:    TAD 76
> 101:    AND 77
> 102:    CLL RAL
> 103:    CIA
> 104:    TAD 76
> 105:    DCA 77
>
> Locations 076 and 077 being ARGONE and ARGTWO respectively, at the start:
> sim> ie 076-077
> 76:     1234
> 77:     4321
>
> After running the above code sample:
> sim> ie 076-077
> 76:     1234
> 77:     0574
>
> If we "flip" ARGONE and ARGTWO's values (to 4321 and 1234 respectively):
> sim> ie 076-077
> 76:     4321
> 77:     3661
>
> Neither of those is the expected 5115 of an XOR operation.
>
> Am I missing something blindingly obvious?
>
>
> Cheers,
> Christian
> --
> Christian M. Gauger-Cosgrove
> STCKON08DS0
> Contact information available upon request.
>



-- 
"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992