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