Machine model

[RE01 Rice Brian T. EM2]

>> 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.  

Wait.  I misspoke.  What I meant was that the machine model would be the
closure of the C-program's abstract services.  It would also be
represented in the environment that the C-program supports, for the
purpose of giving the other objects (the so-called "more abstract"
objects) something to reason about to create new objects and structures.
 Does that clarify?  I do agree with your statements.  However, I have
serious reservations about distinguishing any part of Tunes as "the
metasystem".

>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 disagree about the "more work for us" inference.  By not resembling
machine architecture, and reasoning about this simpler system, we
effectively create a "stepping stone" towards porting the system to the
various hardware systems that exist today, and allow optimizations and
such.  I particularly am interested in developing the logic system quite
fully, and would appreciate a simple machine model to deal with at first
to sort out the issues.  Once I and the system have learned what we need
to move on, then we should leave the unsecure machine-model idea behind,
with the only artifact being the system's representation of hardware
within its objects.

>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

Darn.  All these good links for research are being posted and I haven't
been able to get on the Web for five days or so (more LAN problems...).
Would anyone care to send me some files via e-mail?

>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.

??!?  You're going the take the whatchamacallit and apply it to the
whizbang?