Xref: utzoo comp.lang.c:11311 comp.arch:5464
Path: utzoo!attcan!uunet!mcvax!cernvax!hjm
From: hjm@cernvax.UUCP (hjm)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Keywords: self-modifying code, generate-and-execute
Message-ID: <749@cernvax.UUCP>
Date: 12 Jul 88 09:57:43 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <5254@june.cs.washington.edu> <12357@ut-sally.UUCP> <33441@yale-celray.yale.UUCP>
Reply-To: hjm@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 16

If the program is considered to be data for an interpreter which I will for
convenience call a CPU, then does self-modifying code seem any different?  As
long as the data in this table remains consistent, then there should be no
difficulty in dealing with it mathematically.  All of the problems of database
consistency have been tackled (but not all solved) some time ago.  Code is data
according to a PATCH program, and the only tricky bits there are to ensure that
any changes fit inside the space that they replace and to patch up the jumps
where necessary.  A bit like a structure linked by pointers, such as a binary
tree, except that code is in general a directed cyclic graph (the directedness
is due to the program counter).

Now, if the routines that ensure the consistency of the code change themselves,
then the world will most likely fall down around one's head, but then things get
to be so recursive that my stack oveflows ...

	Hubert Matthews