Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!oddjob!gargoyle!att!alberta!auvax!rwa
From: rwa@auvax.UUCP (Ross Alexander)
Newsgroups: comp.arch
Subject: Re: Execute instructions
Summary: XED was d*mned handy
Message-ID: <681@auvax.UUCP>
Date: 27 Jul 88 07:26:51 GMT
References: <787@amethyst.ma.arizona.edu> <4235@saturn.ucsc.edu>
Distribution: na
Organization: Athabasca U., Alberta, Canada
Lines: 45

In article <4235@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU (99700000) writes:
> So far as I know
> the XED is unique to the GE600 and its successors; in some sense
> it's an artifact of the machine implementation.  [...]
> Or one could say it's
> a case where there isn't really an architecture because it is
> intertwined with the implementation.
> 
> I've always wondered who was (were) the architects on that machine.

XED was quite handy.  It let one insert an extra instruction into
existing binary code with worrying about branch targets et al., by the
simple hack of changing

		op1
		op2
		op3

into

		op1
		xed	fake
		op3

[later]

fake:		op2
		extraop

and there was no impact on the execution of the modified code, since
xed didn't have any linkage overhead or fiddle with the flags.  Since
there was also an add-one-to-storage instruction (aos), I once wrote a
package to take a binary produced by a local B compiler, go through it
finding all the basic blocks, and patching in code via the above hack to
count executions of basic blocks @ runtime; it helped that the compiler
wrote debug-info tables that were easy to find by automated inspection.

Maybe this has some relation to the discussion (elsewhere) on the relative
merits of self-modifying code :-) ?

--
Ross Alexander,
Athabasca University,
Alberta, Canada eh?	[snappy tag-line down for preventative maintenance]

alberta!auvax!rwa