Article View: alt.folklore.computers
Article #210935Re: Most complex instructions
From: mwi... Mel Wilson
Date: Thu, 16 Aug 2001 19:38
Date: Thu, 16 Aug 2001 19:38
89 lines
5433 bytes
5433 bytes
In article <9lh2kk$k6u$1...@freenet9.carleton.ca>,
ab...@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote:
> In the very early 70's, I read about a GE 6xx(?) list processing machine
> instruction. Someone commented that complier writers like those types
> of instructions. Any GE experts in a.f.c-land?
There were three instructions: Repeat, Repeat Double and
Repeat Linked, coded RPT, RPD and RPL. The effect was to
exceute the following one or two instructions up to a set
number of times, with address modification between
executions. Execution was faster because the instructions
were executed out of the processor's instruction registers,
without being re-fetched.
Typical uses:
Presetting a memory buffer to a fixed value (two words at a time):
LDA FIXVAL initializing value
LDQ FIXVAL again
EAX1 BUFFADR address of the buffer
RPT BUFFLEN/2,2 repeat_count and address increment
STAQ 0,X1 repeat this instruction to fill buffer
Block move of words in memory, one at a time:
EAX3 FROMBUF address of sending field
EAX6 TOBUF address of receiving field
ORPD BUFFLEN,1 count and address increment
LDA 0,X3 load from sending area
STA 0,X6 store into receiving area
The 'O' in 'ORPD' was an assembler directive which forced
the RPD instruction to an odd address, because the
instructions being repeated had to occupy an even-odd pair,
so that they would occupy the 72-bit-wide instruction
register together.
The only reserved register for the repeat instructions
was X0 which always held the running repeat-count, and a
whack of control bits, which were filled in from optional
fields in the RPx instruction that I no longer rememeber.
One option caused the existing contents of X0 to control
the process, so that repeat-counts could be computed at
run-time. There were alse options to suppress modification
of either operand address during the repeat, and options to
stop repeating on various indicator register flags. This
let you repeat a compare instruction to do, e.g. a
sequential scan down a table, which might have looked
something like:
EAX5 0 prepare address reg
LDA HILIM look for an entry > this value
RPT TABLENG/6,6,TRC check each 6-word entry for word 1 > hilim
CMPA TABLE+1,X5 compare table word with A reg
TTF FOUNDIT transfer on tally-runout flag Off
... fall through if the search failed
with the effect of running down a table of 6-word entries to
find the first one whose second word exceeded a given value.
IIRC, if the repeat count ran out, the Tally Runout
indicator was set, so the not-found condition could be
handled, as hinted above. On the found condition, the
working address reg. would point at the last operand word.
There was no typical use for the Repeat Linked (RPL)
instruction. Nobody of my acquaintance ever found a use for
it, and we tried. Rather than adding an increment, It would
load the operand address for the next repetition from the
high-order 18 bits of the current operand. You were pretty
much stuck with testing bits in the low-order half of the
word, and any possible application always seemed to need a
little more.
The repeat instructions always ran with interrupts
inhibited because there was no way to save enough processor
state to restart the instruction after an interrupt. This
caused trouble trying to run GCOS code in a Multics system:
a page-fault turns out to be, fundamentally, an interrupt
you don't dare inhibit. Native Multics programs never used
RPT, RPD or RPL; the newer Extended Instruction Set
instructions could do the same things, arguably better. I
never saw enough of virtual-memory GCOS to know if it had
another solution.
All the above IIRC, of course.
Regards. Mel.
Technical Details
Message-ID:
<SFCf7ks/KPLb089yn@the-wire.com>Path:
mbox-mo1.pugleaf.net!archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!sunqbc.risq.qc.ca!news.uunet.ca!nnrp1.uunet.ca.POSTED!not-for-mailReferences:
<jwU87.26231$J37.6143999@typhoon.southeast.rr.com> <vd2NzVOTNb7v-pn2-S9FIPi2udxUW@dialup-63.208.164.94.Dial1.Washington2.Level3.net> <9k3oan$t35$1@top.mitre.org> <vd2NzVOTNb7v-pn2-kRuq3Z30rY3O@dialup-209.244.87.87.Dial1.Washington2.Level3.net> <vd2NzVOTNb7v-pn2-PBomleKh1jJS@dialup-209.244.224.188.Dial1.Washin <9l0m6j$la3$1@top.mitre.org> <K2Tc7.108947$TM5.16755795@typhoon.southeast.rr.com> <6aie7.52269$e%3.8225465@news2-win.server.ntlworld.com> <slrn9no27d.psh.rsteiner@isis.visi.com> <9lh2kk$k6u$1@freenet9.carleton.ca>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!sunqbc.risq.qc.ca!news.uunet.ca!nnrp1.uunet.ca.POSTED!not-for-mail From: mwi...@the-wire.com (Mel Wilson) Newsgroups: alt.folklore.computers Subject: Re: Most complex instructions Message-ID: <SFCf7ks/KPLb089yn@the-wire.com> References: <jwU87.26231$J37.6143999@typhoon.southeast.rr.com> <vd2NzVOTNb7v-pn2-S9FIPi2udxUW@dialup-63.208.164.94.Dial1.Washington2.Level3.net> <9k3oan$t35$1@top.mitre.org> <vd2NzVOTNb7v-pn2-kRuq3Z30rY3O@dialup-209.244.87.87.Dial1.Washington2.Level3.net> <vd2NzVOTNb7v-pn2-PBomleKh1jJS@dialup-209.244.224.188.Dial1.Washin <9l0m6j$la3$1@top.mitre.org> <K2Tc7.108947$TM5.16755795@typhoon.southeast.rr.com> <6aie7.52269$e%3.8225465@news2-win.server.ntlworld.com> <slrn9no27d.psh.rsteiner@isis.visi.com> <9lh2kk$k6u$1@freenet9.carleton.ca> Lines: 90 X-Newsreader: VSoup v1.2.9.37Beta [95/NT] Date: Thu, 16 Aug 2001 15:38:58 -0400 NNTP-Posting-Host: 205.206.39.174 X-Trace: nnrp1.uunet.ca 998056248 205.206.39.174 (Fri, 17 Aug 2001 09:50:48 EDT) NNTP-Posting-Date: Fri, 17 Aug 2001 09:50:48 EDT Organization: UUNET Canada News Reader Service MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit