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