Doing it better 1999-02-08 d ### > I wouldn't (see later). I'm doing one thing differently: the run-time > system is much much smaller. The rest can be written in virtual code > (though it won't, admittedly, be very fast if you do it that way in a > production system). This affects the decision of how low to put the VM, relative to the communication primitives. Not a lot, but it does. Bear it in mind. > one slot per thread (I prefer slot to channel because anyone can send to > it). Another interesting idea. Doesn't it mean that you are throwing away useful information, though? > > *DO NOT UNDERESTIMATE THE AWKWARDNESS OF COMMUNICATION*. > > No, I'm avoiding it. Then you are underestimating it :-) > > Killing a communicatimg process is a right bugger. > > Processes can only kill themselves. i.e. you have to organise things > yourself if you want normal hierarchical control. Ever heard of natural selection? Rabbits? I want a bit more power. Maybe I'm paranoid. > One of the points of this system is that it's so small that there should > be very little to disagree about. We can try different scheduling and > communication mechanisms written in *virtual* code. Ones we like can be > written in C or hand-coded later. Absolutely. A time-slice resource could be an abstract datatype, just like memory. > *You* should be able to understand the C, which will be a) very short and > b) written for clarity and portability. You could understand it thoroughly > by translating it into Java for a doubly-interpreted, doubly-portable and > really *dog-slow* system! A very good way of getting a new system off the ground. I think we've reached percolation threshhold, and should expect to see hundreds of new VMs over the next few years, all written on top of each other. Then we should expect the most inter-implemented group to suffer at the hands of a ruthless coder, and to become very fast. Then we can rule the world. If the above prediction holds, then acceptance of a VM is dependent on the completion of two tasks: - Implementing it on top of an accepted VM. - Implementing an accepted VM on top of it. Preferably, the two accepted VMs should be different, with somebody else having written the former on top of the latter via two others. (Aside: I tell you what: You implement yours on Linux and Risc OS, and implement mine on top of it, and I'll implement mine on Risc OS and implement Risc OS and Java on top of it. No that doesn't sound fair. I know, you do all the work and I'll take all the glory. That sounds better.) This prediction ignores another, absolutely crucial point: you have to offer extremely good libraries, and you have to be seen to develop and support them aggressively. Alistair