Self Modifying Code

Robert R. Henry <>
Wed, 14 Jun 89 11:04:16 PDT

          From comp.compilers

Related articles
Self Modifying Code (Robert R. Henry) (1989-06-14)
| List of all articles for this month |

Date: Wed, 14 Jun 89 11:04:16 PDT
From: Robert R. Henry <>

I am interested in readers' experiences with self-modifying code.

Specifically, I'm interested in knowing of 'standard' programming
tricks that have been used in conjunction with self modifying code, and
in what kinds of programs and on what kinds of architectures self
modifying or self generating code has proven to be useful.

I'm interested in any of these three kinds of self-modifications,
although for the moment I'm focusing on fine-grain modifications:

*fine-grain shape-preserving self modifications (such as changing an
instruction every time through a loop)

*medium/coarse-grain shape-preserving self modifications (similar to
relinking code prior to executing it)

*shape-altering modifications via on-the-fly code generation (this is
used in some bit-blit kernels, and in some interpreters for lisp and

Please don't flame me about system's level issues. I'm perfectly aware
that self-modifying code is not reentrant; is not sharable; it can't
reside in a ROM; it leads to serious cache coherency problems; it isn't
easy to understand; it is architecture and perhaps implementation

Please send mail directly to me, and I'll (eventually) post a summary.

Robert R. Henry
Computer Science Department
University of Washington
[I expect that fine-grained self-modifying code is totally passe due to
problems with prefetch and cache coherency -- even an 8088 prefetches 4 bytes
ahead. The classic place to do medium-level generation is in a sort program.
Mainframe sorts invariably compile the sort criteria into a machine code inner
loop (at least) to make the sort as fast as possible. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.