Doing it better 1999-02-08 c
###

> > I appear to have mis-addressed this e-mail. Did you get a copy too?
>
> I have now.

Sorry. I hope you didn't stay up waiting for it for too long.

> 1. I haven't got as high-level as it yet.

On the contrary, a portable VM is quite high level. I'm being deliberately
provocative: I do understand you. See below.

> 2. I want to do my own thing first for the simple virtue of getting
> something done without distraction. After all, we've been talking about
> the ideas for years, now I want to get some code down.

That is entirely fair.

> > These are all things which we'd otherwise have to worry about all over
> > again.
>
> I'm worrying about them for the first time, I suppose.

If you prefer it that way then I'll not stop you.

> > As for putting too much functionality in the bottom layer (heap,
> > channels): I didn't put the VM there, did I?
>
> No, you didn't have a VM. But for portability I want a VM at the bottom
> (though it's separate from the channels/threads).

See below.

> > ...
> > had very dumb channels. Could we put the code in the channels, to make
> > filters, and have dumb routers at the nodes? Don't know.
>
> This is precisely the sort of question I wanted to avoid. I think my model
> is simple enough that questions of efficiency and organisation can be
> added in later via typing. I want a very simple system (what I've

See below. Also, how does one organise via typing?

> > I think that covers it.
>
> Covers what?

My ideas for the week.



"Below":

We discussed, and agreed, that you want the VM at the lowest possible
level, because it is the only way you can get a good seal separating the
software from the hardware. This arguably remains true, but I'm changing
my mind about the word "possible". I think that what we probably meant to
say is that the VM should be at a lower level than it usually is.  There
are other things which should also be at the "lowest possible level". We
have to make decisions.

To write a VM, you need a heap, however primitive. The VM must be at a
higher level than *a* heap, so why not *the* heap? An interface to
lower-level code is more efficient, and reuses code better, than a
higher-level reimplementation of the same thing. You do have to expend
effort making it a portable interface, though...

The same is not true for communication primitives, without which it is
perfectly possible to make a VM. However, you do need some way of
instructing the VM, and passing it the program. An application model, as
on the BBC B and Risc OS, would do, and is simpler than a full-blown
multi-tasking model with symmetric communication primitives and multiple
threads. But don't we want a nice program environment at the lowest
possible level?

One solution, and one which would make us both right, would be to take
your VM, and build on top of it a heap and some communication primitives,
and build on top of them my VM. We definitely need something restrictive
above the communication primitives before we hand development over to joe
compiler-writer.

I suppose the question is: Is it easier to write a VM in a native
environment and communication primitives and another VM in a portable
environment, or is it easier to write communication primitives and a VM in
a native environment? You reckon the former, and I the latter, or at least
we did yesterday.

I'll think about it.

Alistair