Doing it better 1999-02-01 b ### From Reuben > Sounds like you want to start where my Diploma project left off. Not exactly where it left off, but I did realise that I was going in the same direction. > How'd you like me to help you start there? 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). I also have a simpler model, I think (I remember some nasty issues in yours; ah, I see below that you've remembered). I am avoiding a lot of issues that you addressed in your project by simply not implementing them. I don't have modules, or channels (really). There's one slot per thread (I prefer slot to channel because anyone can send to it). > You also have 1200 bytes of good code towards your communication > primitives. Er, no, *you* have 1200 bytes of good code towards an ARM-optimised version. I'm writing in C for portability. > *DO NOT UNDERESTIMATE THE AWKWARDNESS OF COMMUNICATION*. No, I'm avoiding 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. 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. So what's the point of having such a small VM? Why not write directly in C? Well: 1. It feels nicer writing virtual code that doesn't need a compiler (although there won't be any convenient [I love this European English word] way to do that at first). 2. The code can be sent around the network from day one (or as soon as the system supports it). 3. We can immediately start thinking about what sort of languages and environments we'd *like* to have. For example, one good thing to write fairly soon would be a navigator for debugging (as I said before) plus a Forth-like language for programming. Soon afterwards, it would be nice to write a command-line editor for convenience of use in the navigator, and this would later become the text editor, indeed, it would be the ur-editor of the entire system. > I'd love to influence a project like this. That's why I invited you to do Tau in the first place. Anyway, I hope to come up with a concrete instruction set this evening, then I need to decide exactly what facilities I need for the console, network, CPU and memory (the first four devices), and then I shall nearly be ready to code. Basically, five C files: four devices plus the VM interpreter. The actual code to do the interpretation will look like a series of objects, one per instruction, so that they can be revectored. Then I just need an interface to the system as a whole, which should basically look like a device. I can probably used named pipes under UNIX so you just start the system up and then feed code into it (or better, use a socket, then I don't need an extra device). So the system will start up, listen on a well-defined socket, and you can send it a message to start executing code. Or you can type at the console, but that takes longer... *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! -- http://www.cl.cam.ac.uk/users/rrt1001/ | maxim, n. wisdom for fools