Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: loadable control store, an idea whose time has gone
Message-ID: <4196@goanna.cs.rmit.oz.au>
Date: 5 Nov 90 03:00:44 GMT
References: <1536@ftc.framentec.fr> <1990Oct19.120218.9450@canterbury.ac.nz> <PCG.90Nov2153545@odin.cs.aber.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 23

In article <PCG.90Nov2153545@odin.cs.aber.ac.uk>, pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
> There is no reason for this not to work, and
> it results in impressive code size reductions.

I'm reminded of the old idea of "throw-away compiling".
It seems to me that it might work at the instruction-set level.
The throw-away compiling idea was a hybrid between compiling BASIC
and interpreting it.  What you do is you leave each statement in
tokenised form until you execute it (in fact the first "instruction"
of a tokenised line is a call to the compiler).  Compilation was done
into a "buffer".  When the buffer filled up, it was just thrown away
(hence the name) and compilation started over with the current statement.

Now, imagine a very compact form of code (byte-codes?) held on disc.
When you call a procedure, if it isn't already expanded, you expand it.
The expansion is exactly the kind of work that a micro-coded interpreter
would do anyway, except that you're storing the results into a buffer
instead of executing it.  This may involve fetching the byte-code string
from disc.  When a code page is to be "paged out", you just throw it away,
preferring to keep byte code strings in memory.
-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.