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