Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Self modifying code Message-ID: Date: 3 Jun 91 15:28:21 GMT References: <1991May30.005339.14067@cs.umu.se> <1991Jun2.091922.13501@unislc.uucp> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 33 In-Reply-To: ttobler@unislc.uucp's message of Sun, 2 Jun 91 09:19:22 GM In article <1991Jun2.091922.13501@unislc.uucp> ttobler@unislc.uucp (Trent Tobler) writes: But that was just an example. Suppose I want to write an interactive language that compiles directly to machine language which I may choose to then execute (I believe JForth does this?) Picking a nit, that's not self-modifying code, but just generating code. Unfortunately, the problem being discussedd isn't really self-modifying code, but data/code confusion. Self-modifying code is just one of the most common examples of that technic. LISP macros are another common example. Coding time can be reduce by leaps and bounds if after I type the definition of a command, I can test immediately without doing the compile-link-run sequence from the operating system. So, what is a good way to implement this type of thing? Well, in the face of an architechture that doesn't allow you to directly turn data into code, you have to use the tools provided for doing so, and follow the protocols. For testing the interpreter, I'd probably generate code to a scratch file on ram:, and loadseg that. This has the advantage of leaving the code where it can be readily examined and fooled with. For production, I'd probably gen code to memory and play the game "right", and investigate gen'ing code into the resident list (that might make things easier; or it might be a total lose. Finding out is why I'd investigate it).