🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.folklore.computers
Article #210935

Re: Most complex instructions

#210935
From: mwi... Mel Wilson
Date: Thu, 16 Aug 2001 19:38
89 lines
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-mail
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>

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