Related articles |
---|
Self Modifying Code rrh@june.cs.washington.edu (Robert R. Henry) (1989-06-14) |
Date: | Wed, 14 Jun 89 11:04:16 PDT |
From: | Robert R. Henry <rrh@june.cs.washington.edu> |
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
smalltalk)
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
dependent.
Please send mail directly to me, and I'll (eventually) post a summary.
Thanks,
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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.