Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Keywords: self modification, code generation, Seymour, CDC, FAST!
Message-ID: <361@scolex>
Date: 17 Jul 88 00:44:27 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <1276@edge.UUCP>
Reply-To: seanf@sco.COM (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Lines: 47

In article <1276@edge.UUCP> gregr@edge.UUCP (Greg Rose) writes:
[brief summary of the SM code discussion]
>"Self modifying code" such as was used on early computers, for example
>early CDC 6600 machines (not flaming them, just the example I know)
>was a NECESSARY technique for performing subroutine linkage. There was no
>instruction to perform a jump to an arbitrary address (i.e. the return
>address of the subroutine) so the subroutine entry code *had* to overwrite
>a jump instruction's operand (at a known, per subroutine, address) before
>calling. This was usually the instruction immediately at or before the start
>of the subroutine. In psuedo code:
>
[sample pseudo code]

NO NO NO NO!!!!!! The CDC 6600 (and 7600, and the Crays, as well) had a Jump
to Subroutine instruction:  RJ  (Return Jump) (on the 6600); what this
would do is write a  into  (the
machine could pack up to 4 instructions in a word [60 bit words, 15 or 30
bit instructions], so the assembler had to look for labels for RJ
instructions and pad out the rest of the word with NOPs 8-)).  (The machine
did this because it lacked one simple little feature found on many of
today's machines:  a stack.)  Therefore, when you did a RJ, it would perform
the indicated write, and start execution at +1, and, to return, you
would JP (or do an unconditional branch, which wouldn't clear out the
instruction cache) to the entry point, and boom! you're back where you want
to be.  Because of other features of the machine (such as banks of memory
[i.e., the memory was accessed as one of 8(?) banks of RAM, with each
succeeding address in a different bank.  Accessing any individual address could
be, oh, 8 times slower than the machine cycle, but accessing the next
address wouldn't be.  Therefore, when you did an RJ, it could write to
, and then get  at the next cycle], and the fact that you
could write to a location and execute another instruction [instruction
overlap]), this was *much* faster than having to maintain a stack would be,
and it also didn't tie up any of the registers (it only had 24 of them, one
of which was hardwired to 0, one of which was usually 1, and 7 of which, if
accessed, would either screw up memory or another register).

They were very fast machines, as I've said here before.  If only they didn't
have NOS...

>Greg Rose, Softway Pty Ltd, Australia
>...uunet!munnari!greg@softway.oz

Sean.
---------------
Sean Eric Fagan
seanf@sco
(408) 458-1422, ext. 3561