Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ksr!clj
From: clj@ksr.com (Chris Jones)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <563@ksr.UUCP>
Date: 12 Oct 89 13:57:02 GMT
References: <6481@pt.cs.cmu.edu> <9175@etana.tut.fi>
Sender: nobody@ksr.UUCP
Reply-To: clj@ksr.com (Chris Jones)
Organization: Kendall Square Research Corp
Lines: 26
In-reply-to: pl@etana.tut.fi (Lehtinen Pertti)

In article <9175@etana.tut.fi>, pl@etana (Lehtinen Pertti) writes:
>
>	I've been lately wondering if there is any architecture
>	with possibility to execute instruction indirectly.
>
>	I mean something like:
>
>		exec r0	; execute instructio in register r0
>
>	or
>
>		exec (r0)	; execute instruction pointed by r0

We used to do this on Data General (16 bit) Eclipses.  Peripherals on the
machine were addressed by device codes, and the I/O instructions had the device
codes as part of the instruction (rather than being taken from a register).  To
allow the same code to service more than one device, we'd build an I/O
instruction in a register, then execute it out of the register.

The GE/Honeywell 635/645/DPS-8 line had both XEC (execute) and XED (execute
double) instructions, used to implement one or two instruction subroutines.

By the way, the instruction format on the those machines was a 36 bit word,
with the 18 bits of address in the upper half of the word.  I have been told
the reason for this is so that self-modifying code wouldn't destroy opcode bits
if address manipulation caused a carry out of the address field.