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"