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