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