Xref: utzoo comp.lang.c:11289 comp.arch:5452 Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Keywords: self-modifying code, generate-and-execute Message-ID: <23821@think.UUCP> Date: 15 Jul 88 06:06:32 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <5254@june.cs.washington.edu> <12357@ut-sally.UUCP> <33441@yale-celray.yale.UUCP> <749@cernvax.UUCP> Sender: usenet@think.UUCP Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 32 In article <749@cernvax.UUCP> hjm@cernvax.UUCP () writes: >If the program is considered to be data for an interpreter which I will for >convenience call a CPU, then does self-modifying code seem any different? As >long as the data in this table remains consistent, then there should be no >difficulty in dealing with it mathematically. All of the problems of database >consistency have been tackled (but not all solved) some time ago. Code is data >according to a PATCH program, and the only tricky bits there are to ensure that >any changes fit inside the space that they replace and to patch up the jumps >where necessary. A bit like a structure linked by pointers, such as a binary >tree, except that code is in general a directed cyclic graph (the directedness >is due to the program counter). This view is valid, but simplifies the issues. If you are going to think of the program as a database, you must actually consider it as a distributed database. This is because the data is replicated in several places: the physical memory, the swapping device, the CPU caches, and internal processor registers. The problems of maintaining consistency in replicated databases is much less understood than concurrency control in non-distributed databases. Additionally, any form of consistency maintenance must incur some performance penalty, and hardware designers are under great pressure to make machines go as fast as possible. Multiple caches that do not maintain consistency are one answer to this. Since self-modifying code has generally been considered bad style for quite some time, they felt comfortable implementing a hardware optimization that assumes code will not modify nearby locations. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar