Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!noao!nud!sunburn!gtx!edge!gregr From: gregr@edge.UUCP (Greg Rose) Newsgroups: comp.arch Subject: Re: Self-modifying code Summary: clarify usage of the term "self-modifying" Keywords: self modification, code generation Message-ID: <1276@edge.UUCP> Date: 14 Jul 88 18:01:59 GMT References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> Reply-To: gregr@edge.UUCP (Greg Rose) Organization: Edge Computer Corporation, Scottsdale, AZ Lines: 55 The discussion of self modifying code, as it has progressed in this newsgroup, will never reach an end. This is simply because the opponents and proponents are not talking about the same things at all. "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: /* caller */ /* callee */ ld r0,#ret_addr subr: jmp anywhere /*TBA*/ st r0,subr+1 ... jmp subr+2 ... ret_addr: jmp subr /* return */ ... (Assume that it is word addressed and the jmp instruction takes one word, as does its operand.) THIS is self modifying code at its worst, gaaakk phut, urk, where is the bathroom. Ever wondered why the early Fortran standards didn't even *allow* recursion? Even earlier machines used similar techniques for array indexing and other irrelevant stuff. "Run time generated code" is a whole different kettle of fish, and seems to be what all of the proponents in the discussion have been referring to. This is where issues such as separate I/D spaces/caches, operating system support, and so on, come in. BITBLT is, as noted, the classic example where run time generated code can do the job much faster than any parameterised loops. But load-and-go compilers are also a sensible thing in some environments. The only difference between generating code in your own address space and jumping to it, or generating it in a file and 'exec'ing it, is that the operating system knows how to do the latter correctly. Nobody really objects to optimising compilers, now do they? So what is the problem with optimising code generators for some other class of problem. I agree with John Mashey that the most needed thing at the moment is appropriate operating system or hardware support to address the caching and accessability issues. The second most needed thing is to stop calling "run time generated code" "self modifying code" so people will think before barfing. Greg Rose, Softway Pty Ltd, Australia ...uunet!munnari!greg@softway.oz "Assume your favourite disclaimer since I don't think I need one"