Machine model

[Tril]

On Mon, 26 Oct 1998, RE01 Rice Brian T. EM2 wrote:

> The machine model's language space will contain the machine model.
> Otherwise, how would it's services(?) be invoked by an automaton of
> reason?  Extending this model and coincidentally extending the model's
> representation will be a key learning experience for us, I believe.

I don't like the way you are using 'machine model'.  It seems you are
using it to refer to the entire system.  In my idea of TUNES, the machine
model makes up only part of the system, the part that relates to hardware.
The rest of TUNES won't (necessarily) resemble the design of hardware at
all.  The less TUNES resembles current machine structures, (and the
more it uses some easy-to-understand paradigm for the universal
metasystem) the better.  

Not resembling machine architecture, of course, creates more work for us,
because there is a much larger space between the system design and the
implementation.  But that is good if the system is easier for users to
understand.  So what if it takes more steps to be modelled on a machine.
New machines can be designed, after all.

I believe the optimal platform for TUNES is an array of FPGA such as the
one announced at http://www.slashdot.org/articles/98/10/27/1259212.shtml

Here's how I think of the structure of the system:
1. TUNES metasystem (reflectively bootstrapped by running #4 on #2)
2. Specification of #1 (written in #1)
3. Machine model (written in #1)
4. Translator from #1 -> #3 (Written in #1)

The machine model obtains reflection only indirectly: by being written in
#1, it is a valid object of the translator.

>From your description I got some idea of a simple machine model written in
itself.  Correct me if I was misled.  (Also it is fine to have a different
system architecture than I have.  Or maybe you intend to eventually evolve
into something like the above.)

David Manifold <dem@tunes.org>