2008/5/12 Russell Wallace <[EMAIL PROTECTED]>: > On Mon, May 12, 2008 at 10:52 AM, William Pearson <[EMAIL PROTECTED]> wrote: > > So let us get back to the problem a new process is being trialled. > > Whichever process is creating the new process, will set it up with its > > own domain, a bank and put some credit in it. Then pay some credit to > > register it with a low priority scheduler. > > Right, that's cool. The aspects I'm curious about are still much lower > level - by "process", do you mean an operating system process, or are > you going to write a VM, or use an off the shelf one?
It will be a process inside a heavily modified QEmu VM. I'm taking baby steps towards modding the Sparc architecture in QEmu as that has the biggest open hardware following, and should be relatively clean compared to the heavily crufty x86 arch. But time is lacking at the moment to learn the arch properly. My low level coding skills could use a brush up as well. Things I will change about the arch include, BIOS stage, MMU and memory protection I'll also add domain and capability creation/destruction instructions. I could possibly create my own arch a lot more quickly, but it would be no where near as optimised or as cross platform. And I would have to figure out about interfacing with displays and other IO more than I have to do if I mod QEmu. > What will the > programs consist of, machine code, byte code, Lisp S-expressions...? > Machine code initially. Although I plan to create a C compiler + extensions to run on the system and then further languages to be added as needed. Compilers and interpreters are likely to very credit rich systems, but they will have to be a lot smarter in how they use those credits, than they are at the moment. Lisp S-expressions hide too much of the underlying resources being used, although to be honest I don't know how the Lisp based machines work, a version of them may be possible. But I figure work with what the most people know at the moment. I would like to go to a more parallel computer system in the future with persistent memory. > (I'm of the opinion that systems of the type you propose are > potentially a good idea, but are likely to succeed or fail based on > the nitty-gritty engineering details.) > True, there are a number of issues. Things like loading programs from persitant to transient memory are problematic (having a single program responsible for booting the whole system is not advisable IMO). My rules of thumb are 1) Avoid giving one program the ability to muck up/take over all the other programs as much as possible 2) There are more ways that a program can do this, than you can initially think of, look harder. If I could find a sufficient group of people interested in this topic I would branch off a mailing list. Will Pearson ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
