Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <274@ssp1.idca.tds.philips.nl>
Date: 16 Oct 89 17:44:43 GMT
References: <6481@pt.cs.cmu.edu> <9175@etana.tut.fi> <1619@atanasoff.cs.iastate.edu> <672@sce.carleton.ca> <480@gp.govt.nz>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 63

In article <480@gp.govt.nz> don@gp.govt.nz (Don Stokes, GPO) writes:
>In article <672@sce.carleton.ca>, cassel@sce.carleton.ca (Ron Casselman) writes:
>> I seem to remember a piece of self-modifying code that used to run
>> on CP/M. I remember it because I had to disassemble it as an assignment for
>
>Sounds a little like DDT (Dynamic Debugging Tool).  If you type DDT
><program> DDT starts itself up at the bottom of the TPA (at this stage,
>DDT is just a normal COM file), slides itself into high memory and loads

Didn't DDT use relative addressing? Something vaguely tells me that DDT
could (block) copy itself to another address. If it used relative 
addressing then I don't think it needed to self-modify.

Who would have thought that SMC would've been a me-too thread :-)?
Anyways heres my me too contribution:

Many moons ago I had a cute little Z80 micro called a Jupiter Ace and 
had those elegant little rubber keypads which were specially designed for 
the one finger-push hard typists. 
For those of you who have never heard of this magnificent machine: 
it was designed by the same guys who did the ZX-81. They left 
Sinclair's company, founded their own startup company and neither they nor 
the Jupiter Ace were ever heard of again. But I'm digressing...

The Jupiter Ace had a Forth intepreter in rom (8k - of which 2k was a
character set generator - oh for the good old days...). What I wanted
to do was use the interpreter to trace through itself at the Z80 instruction
level. Now the Z80 didn't have any support for trace instructions on
the one hand and I didn't want to write code to interpret the 600 odd
cases that the Z80 had on the other. 

I came up with the following little routine:

		save real registers/condition codes 
		load registers/condition codes from emulated registers

		nop
		nop
		nop
		nop

		save registers and condition codes to emulated registers
		load real register/condition code values


By loading the instruction I wanted to trace in the area with nop's
and calling the routine I could let the Z80 "calculate" the condition codes 
and the changed registers for me. The next step was to calculate the
new pc and load the following instruction to be traced.

Of course, this was pretty primitive. It wouldn't work for branches
(but I could determine if a branch would take place and set the 
emulated pc accordingly and continue from there). Nor would it
work for io instructions :-) but they didn't occur often anyway.

Primitive or no it helped me trace through the interpreter. 
Wonder if the Ace is in the attic somewhere...:-)
 
-- 
Artificial Intelligence: 
When computers start selling stocks because its Friday the 13th....
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof