I've decided that a slight change of name is in order. The project is now officially the Khavi Virtual Machine Framework.

This name change is prompted by the fact that I have now added support for the instruction set of the Lua virtual machine. This will be included in the default release and will allow the framework to emulate both stack based and register based virtual machines.

So is Khavi a random name you invented?

Nice work here! The fact that it's going to support LUA is pretty sweet too! =)

Here's a quick description of how Khavi works, for anyone who'se interested:

When a program is opened from the shell, the shell recognizes the extension and passes it on to Khavi, along with some other information such as a pointer to the program. If Khavi hasn't been opened in a thread before, then it overwrites the Interrupt table to set up its thread manager, starts it, and passes control to what will become the primary thread. Back in the thread, Khavi looks up the proper parsing algorithm in a table and jumps to that algorithm. Each algorithm goes through the file header and extracts all of the useful information from it. Once that's completed, Khavi selects the proper interpreter to parse the bytecode with.

The interpreter for each type of bytecode is mostly custom and implements a complete instruction set for the virtual machine as well as the interpreter itself. The Khavi framework itself imposes no restrictions on each interpreter and they can do as they like. This allows each interpreter to be as powerful as the designer wants them to be. However, it also means a lot of redundant code with multiple languages written in. Therefore, Khavi also offers a small library of "threadcalls" to do common things like add float point numbers, write strings to the screen. It also provides programs with ways of doing things that would be extremely difficult to do within the confines of the instruction set itself, such as passing arguments to other threads.

Behind all of this lies the Thread manager (or context switcher, if you prefer). This component transparently handles the threading so that no individual thread is aware of the fact that it isn't always operating. Its other important task is to handle interactions between threads as well as manage their interaction with the rest of the system, both of which are done through the "threadcalls."

There's actually a lot more small stuff going on with cache management and the heap, but that's the simple explanation 

It's a virtual machine for any instruction set that has been written for it. That's currently Java and Lua.

it could quite possibly support emerald, though most likely not as optimized because most instructions in the Emerald Opcode Language are controlled primarily by the VM (there's only even 1 math command that tells the VM to evaluate the expression and perform all lower-level math specified) -- most of the opcodes are even undo-able without support for Emerald Ideals.  Maybe we can collaborate for an emerald extension later on, but for now I don't think it would fare very well

GCC-based code can be pretty darn close to assembly code if it weren't GCC or LLVM, I would be concerned -- but GCC is close enough, ~10 more cycles doesn't hurt anything

Also, qwerty, I think your VM is a bit different than mine -- yours is more low-level in the sense it does the bare bones interpretation, whereas mine basically wraps the program around like a snake 5 coils around and acts as a whole surrogate OS in a sense.  Emerald is meant to be ran on a more suitable environment meant for emerald-only programming (of course any language that can compile to Emerald Bytecode is welcome, though) because the VM and the program react almost as two living creatures, as it implements my "Living VM" theory.

It's kind of both, except I haven't added support for external libraries (not that it would be terribly difficult). Khavi is a standalone program except in that it needs certain arguments to be passed to it when it's booted. After that, it will be able to run independently of other programs. I will be releasing an official version supporting multiple languages to reduce the number of add-ins necessary. However, anyone who wants to will be able to use the Kavi framework with minor changes to the actual interpreter and only have to write the instruction set, so it's a framework in that sense.

BASIC, though, presents some special challenges to bytecode interpretation, since it's not pure bytecode. You'll need to tokenize the arguments and the expressions, which is where you're going to lose a lot of speed.

I could write it in, since the ON button normally isn't used anyway.