Self-modifying code

[pri=-10 Stuart Lynne]

In article <752 at cernvax.UUCP> hjm at cernvax.UUCP () writes:
>I have been mulling over the idea of self-modifying code (SMC) for a while and
>I've come to the conclusion that there is no good definition of SMC.

>For example, if treating code as data is the definition, then does passing a
>procedure as a parameter in PASCAL, or a pointer to a function in C count?
>Probably not.

>OK, what about a jump table.  Consider an array of pointers to functions in C.
>Does changing the pointers count as SMC?  Again, I don't think so.

>So, changing a pointer by assigning to it is not SMC, but putting a new jump
>instruction in (e.g. jmp #somewhere_else) in place of an existing instruction
>is SMC.  Does one level of indirection really make that much difference?


A simple definition might be any program that cannot be compiled and run
in shared text mode (or equivalent for non Unix application environments).

Modifying a jump table in your data space does not affect how the program
will run for other users. 

Modifying a jump instruction in the shared text *will* affect how the
program will run for other users.


I have used SMC in places that where by design not required to be shared and
where a high degree of efficency was required. For example in a p-System
type interpreter you need to have a test in the opcode fetch and dispatch
loop for a pseudo interrupt. This takes a lot of time. By simply patching in
a jmp to_int as the first instruction of the loop we eliminate the need for
an explicit test. 

To make the above example work for multi-user systems, we used a jump
indirect through a var which contained either the ifetch address or
interrupt handler address. A little slower but still faster than explicit
test in the ifetch loop.

Similiar type of problems can arise when doing high performance device
drivers. 


-- 
Stuart.Lynne at wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532