Xref: utzoo comp.lang.c:11369 comp.arch:5535 Path: utzoo!attcan!uunet!husc6!mit-eddie!killer!elg From: elg@killer.DALLAS.TX.US (Eric Green) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Message-ID: <4818@killer.DALLAS.TX.US> Date: 17 Jul 88 03:53:07 GMT References: <4776@killer.UUCP> Organization: The Unix(R) Connection, Dallas, Texas Lines: 56 in article <4776@killer.UUCP>, chasm@killer.UUCP (Charles Marslett) says: > 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. Uh, I don't know what systems you're talking about, but for the small microcontrollers that I've used -- the ROM is assembled to be placed in the memory map at an absolute location. That is, it takes up the same amount of space whether it's in ROM or RAM (in fact, one of my favorite hardware designs is a little SRAM card that I use to spoof ROM for prototyping purposes). As for re-using memory buffers etc., those are always in RAM, so those are always re-usable -- no matter where your executable is loaded. 32K bytes of ROM costs about 1/4th of what 32K bytes of static RAM costs (not to mention the eliminating-need-to-load). Note that these are dedicated control systems using 6502's, Z-80's, and 6809's, which have a total address space of 64K -- so 32K of ROM is a heckuva lot. > 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}===<<). Actually, RISC may be the stake-in-the-heart of self-modifying code. RISC technology overcomes the increased memory bandwidth requirement by using enhanced cache technology, 256-byte-at-a-time prefetch from page-mode DRAM's, heavy pipelining, and every other trick in the book. Most of which are quite contrary to the thought of self-modifying code. Another RISC trick is to use the saved silicon for extra registers, and have the compilers keep as many valus as possible in the CPU registers. You can always do a one-word memory-indirect load off of a register much faster than you can do a "memory-write(the address into the instruction) memory-read(the address part of the modified instruction) memory-read" triplet (which is at least three two-word instructions, as vs. a single one-word instruction, on a machine where one cycle = one word processed). But, I HAVE done self-modifying code on a 6502-based microcontroller (out of sheer necessity). I still make an occasional enhancement to that software, over 3 years later, as new applications arise, and have had no problems with readability. After all, in assembly on a microcontroller, you have to save the address somewhere, and the fact that the "somewhere" happens to be inside an assembly language instruction makes little difference. The argument against self-modifying code lies elsewhere besides readability. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 MISFORTUNE, n. The kind of fortune that never misses.