Xref: utzoo comp.lang.c:11295 comp.arch:5458 Path: utzoo!attcan!uunet!husc6!mit-eddie!killer!chasm From: chasm@killer.UUCP (Charles Marslett) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Summary: ROM is smaller than RAM? Keywords: self-modifying code, generate-and-execute Message-ID: <4776@killer.UUCP> Date: 12 Jul 88 02:18:12 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33441@yale-celray.yale.UUCP> Organization: The Unix(R) Connection, Dallas, Texas Lines: 23 In article <33441@yale-celray.yale.UUCP>, lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: > 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. On the other hand, some RAM based systems require 4 Mb to run an editor, so you may be right in those cases :->} !! Seriously, newer architectures have reduced the difference (to 0 perhaps), but the emphasis on RISC these days may resurrect self-modifying code -- a RISC-er technique is not known to mankind! (:-D}===<<). > Bjorn Lisper Charles Marslett