23 Dec
2015
23 Dec
'15
10:50 p.m.
On 12/23/2015 7:14 PM, Christian Gauger-Cosgrove wrote:
On 23 December 2015 at 13:44, CLASystems
<clasystems at gmail.com> wrote:
I think there was just a bit of brain fade in the original listing. From
DEC-08-FFAA-D PDP-8 Math Library circa 1968
the XOR routine is as follows, transcribed to SIMH:
sim> de 76 1234
sim> de 77 4321
sim> ie -m 100-107
100: CLA CLL
101: TAD 76
102: AND 77
103: CIA
104: CLL RAL
105: TAD 76
106: TAD 77
107: HLT
sim> go 100
HALT instruction, PC: 00110 (AND 0)
sim> ex ac
AC: 5115
Which produces the correct result in the AC. Locations 103/104 were swapped in
order, and location 106 was left out.
And for completeness location 100 was added to initially clear the AC/Link.
Don
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
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