Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!iuvax!pur-ee!a.cs.uiuc.edu!p.cs.uiuc.edu!gillies From: gillies@p.cs.uiuc.edu Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <76700032@p.cs.uiuc.edu> Date: 13 Jul 88 01:27:00 GMT References: <5254@june.cs.washington.edu> Lines: 29 Nf-ID: #R:june.cs.washington.edu:5254:p.cs.uiuc.edu:76700032:000:1443 Nf-From: p.cs.uiuc.edu!gillies Jul 12 20:27:00 1988 I think many rules have an exception (e.g. "gotos considered harmful"). There is a difference between self-modifying code and non-reentrant code. Today, people are finding new uses for self-modifying code that were unforseen 20 years ago: 1. Simple programs that need OPTIMAL speed, and would be outrageously expensive on ANY machine. The major example is BITBLT, a subroutine with about 10-15 parameters that does a massive amount of linear-time work. If the BITBLT subroutines generates the machine code expressly for the particular arguments, you can save a factor of 3 or more in speed. This is very important for interactive graphics. 2. Peter Deutsch and PARCPLACE systems used a new technique to speed up Smalltalk on conventional computers. When a subroutine is executed, the types are checked and if possible, the subroutine is compiled for speed & executed. Then this compiled code is cached for possible use later, when the arguments have the same types. This also gave a very large constant speedup to the smalltalks marketed by ParcPlace systems. I think papers on both these techniques appeared in the first OOPSLA conference. In light of these new techniques, I believe it's time to reexamine our opinions about self-modifying code. Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies