Self-modifying code

[Barry Margolin]

In article <749 at cernvax.UUCP> hjm at 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 at think.com
{uunet,harvard}!think!barmar