Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (Seima Rao) (2014-03-07) |
| Re: Self-modifying code, Function pointers & { Safety, Security} kaz@kylheku.com (Kaz Kylheku) (2014-03-09) |
| Re: Self-modifying code, Function pointers & { Safety, Security} martin@gkc.org.uk (Martin Ward) (2014-03-14) |
| Re: Self-modifying code, Function pointers & { Safety, Security} tenger@iseries-guru.com (Terrence Enger) (2014-03-15) |
| Re: Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (2014-03-20) |
| Re: Self-modifying code, Function pointers & { Safety, Security} federation2005@netzero.com (2014-04-13) |
| Re: Self-modifying code, Function pointers & { Safety, Security} monnier@iro.umontreal.ca (Stefan Monnier) (2014-04-16) |
| From: | seimarao@gmail.com |
| Newsgroups: | comp.compilers |
| Date: | Thu, 20 Mar 2014 00:42:20 -0700 (PDT) |
| Organization: | Compilers Central |
| References: | 14-03-015 |
| Injection-Date: | Thu, 20 Mar 2014 07:42:21 +0000 |
| Keywords: | design, code |
| Posted-Date: | 20 Mar 2014 10:30:51 EDT |
> [The major reasons for self-modifying code historically were for
> address modification for indexing and subroutine returns. Index
> registers and indirect addressing provide instruction modification as
> the instruction is executed, making those modifications go away. For
> runtime code generation, there have been a variety of approaches to
> controlled addition of code to running programs, which I could dig up
> if people care. -John]
I was planning to discontinue self-modifying code entirely.
For runtime code generation, I was planning to bank entirely
upon runtime hooks(mapping instructions of an interpreter to
API hooks).
I will proceed on these two premises if only others advised.
Sincerely,
Seima Rao.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.