Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bls
From: bls@cs.purdue.EDU (Brian L. Stuart)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <8339@medusa.cs.purdue.edu>
Date: 17 Oct 89 19:52:59 GMT
References: <6481@pt.cs.cmu.edu> <9175@etana.tut.fi> <1619@atanasoff.cs.iastate.edu> <855@sdrc.UUCP> <33557@ames.arc.nasa.gov>
Reply-To: bls@cs.purdue.edu (Brian L. Stuart)
Organization: Department of Computer Science, Purdue University
Lines: 23

In article <33557@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>Some of this discussion reminds me of discussions about threaded-code systems
>like Forth.  Has anyone ever identified any ISA issues that are specific for
>code like this?  I have always assumed that a fast branching RISC would be
>ideal, but I don't know of this is a correct assumption.
>
>  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster

This would in fact be quite useful in some Forth implementations, but those
implementations really do not utilize self-modifying (or compile-on-the-fly)
code.  The Forth compiler I wrote (which did compile-on-the-fly and some
really strange stack manipulations) would have benefited most from a VERY
fast and simple subroutine linkage.  (What I had wasn't really bad at all;
it was a PDP-11.)  The reason for this is that the executable code I generated
consisted completely of JSR's, MOV #xxx,(R5)+'s, and RTS's.  (The R5 being
because that was my data stack pointer.)  The primitives were coded in
PDP-11 assembler and would have been well served by any standard RISC,
though some of the 11's addressing modes were handy.

Brian L. Stuart
Department of Computer Science
Purdue University