Xref: utzoo comp.lang.c:11276 comp.arch:5437 Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!husc6!yale!lisper-bjorn From: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Keywords: self-modifying code, generate-and-execute Message-ID: <33518@yale-celray.yale.UUCP> Date: 12 Jul 88 21:17:52 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33441@yale-celray.yale.UUCP> <4776@killer.UUCP> Sender: root@yale.UUCP Reply-To: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 21 In article <4776@killer.UUCP> chasm@killer.UUCP (Charles Marslett) writes: >In article <33441@yale-celray.yale.UUCP>, I write: >> Another related issue is that self-modifying code cannot be executed >> directly from ROM. Executing programs in ROM is an important memory-saving >> technique in small, diskless, special-purpose systems. > >Actually, I always thought that ROM was much more important as a way of >eliminating the need to load the code and as a way of guaranteeing non- >self-modifying-ness. Usually ROM code is larger (thus memory-consuming) >than RAM-loaded code. This is because most RAM based systems assume some >form of selfmodification of code, ranging from relocation tables that avoid >the need for self-relative addressing everywhere to file initialization code >that gets overwritten by its own buffer.... As I wrote was actually thinking primarily of diskless systems. In such a system the program is stored in ROM. If the program is self-modifying, its code has to be loaded into RAM before it can execute. If not it can be executed directly in ROM and only the data areas need to be RAM. Thus memory is saved (we don't need the extra RAM to hold the code). Bjorn Lisper