chuck@dartvax.UUCP (Chuck Simmons) (03/06/86)
> We DO have the formal discipline to use self-modifying code: > it's called incremental compilation. > > For some specific instance of a general routine with all sorts of > ifs depending on parameters values, take a general prototype with all > the ifs in it, compile only the parts you need into a buffer, and then > execute that buffer. How does this differ (conceptually) from invoking a subroutine which has its own local memory and passing it parameters? Chuck Simmons chuck@dartvax
bruce@stride.UUCP (Bruce Robertson) (03/06/86)
A point of interest (at least to me) is that the 68020 with cache enabled does not support self-modifying code. The CPU doesn't support writing to the cache. I'm not sure what happens if you try, but it's sure not to succeed. -- Bruce Robertson UUCP: cbosgd!utah-cs!utah-gr!stride!bruce ARPA: stride!bruce@utah-gr.arpa
henry@utzoo.UUCP (Henry Spencer) (03/16/86)
> > For some specific instance of a general routine with all sorts of > > ifs depending on parameters values, take a general prototype with all > > the ifs in it, compile only the parts you need into a buffer, and then > > execute that buffer. > > How does this differ (conceptually) from invoking a subroutine which has > its own local memory and passing it parameters? Conceptually, not at all. Practically, quite a bit. Making choices during compilation is generally faster than making them at run time. If the code is going to be used enough to justify the compilation overhead, compiling will be a considerable win. It also gives you access to a huge number of different alternatives without having to write, compile, and store all of them in advance. (If you don't think this is significant, try enumerating the different cases of something like an efficient BitBlt implementation. Thousands of different code sequences.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
aglew@ccvaxa.UUCP (03/20/86)
>/* Written 3:20 am Mar 6, 1986 by chuck@dartvax.UUCP in ccvaxa:net.arch */ >/* ---------- "Re: Self-modifying code" ---------- */ >> We DO have the formal discipline to use self-modifying code: >> it's called incremental compilation. >> >> For some specific instance of a general routine with all sorts of >> ifs depending on parameters values, take a general prototype with all >> the ifs in it, compile only the parts you need into a buffer, and then >> execute that buffer. > >How does this differ (conceptually) from invoking a subroutine which has >its own local memory and passing it parameters? > >Chuck Simmons chuck@dartvax The difference is that the maximum number of ifs are evaluated at compile time rather than run time. Obviously, it isn't the only type of compilation possible. My point is that the concepts underlying `self-modifying code' are portable at the macro level of subroutines, rather than at the micro level of fields in instructions. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ...!ihnp4!uiucdcs!ccvaxa!aglew ARPAnet: aglew@gswd-vms