Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!nsc!voder!apple!baum From: baum@Apple.COM (Allen J. Baum) Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <13984@apple.Apple.COM> Date: 15 Jul 88 02:00:16 GMT References: <5254@june.cs.washington.edu> <28200177@urbsdc> Reply-To: baum@apple.UUCP (Allen Baum) Organization: Apple Computer, Inc. Lines: 30 [] >In article <28200177@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: > >>Today, people are finding new uses for self-modifying code that >>were unforseen 20 years ago: >> >>1. ... BITBLT ... >> >>2. Peter Deutsch and PARCPLACE systems used a new technique to speed >>up Smalltalk on conventional computers... >> This was supposed to be a reply to Doug Pardo, but the Brain-Damaged-Mailer bounced the reply, so I'm posting... What about the case mentioned by someone for speeding up SmallTalk? In this case, you're compiling a small routine, instead of the whole program, but have the same information. HP used something like this for a fast APL compiler long ago in a galaxy far away. They compiled code for adding to objects according to the object types at compilation time, and the code included a check for just those types. If the check failed, it bounced back to the compiler, which generated code for a more general case; so, for example, the first time it might compile code for arrays of size i=constant, and if the size changed, then it would compile slightly more general code for arrays of size n=variable, then if that also failed, maybe for arrays of rank m=var, size n=var, etc. It ran much faster than interpreters running on faster machines so it can be a big win. Again, in all cases, you know which addresses to flush before you branch to them. -- {decwrl,hplabs,ihnp4}!nsc!apple!baum (408)973-3385