Cybiko Bytecode Interpreter

Reasons For Inventing The Wheel

The Cybiko computer is built around the Hitachi H8S processor which, from the programmer's point of view, has many nice features, most notably excellent instruction timing, 32-bit architecture (including a "flat" address space), and plenty of registers. When you need to squeeze the last cycle out of some time-critical piece of code, control hardware, or manage power savings, the H8S is great. But when it is necessary to come up with short programs, the H8S fails. There are several reasons for this:

1. The H8S is a successor to a 16-bit processor, designed to maintain maximum compatibility with its predecessor. These Hitachi processors might appear to be like the Intel i80x86 processors at first glance. But while (in 32-bit "flat" mode) Intel "sacrificed" 16-bit instructions (whenever you employ an instruction that operates upon 16-bit operand[s], it gets prefixed with an extra byte), Hitachi "sacrificed" some 32-bit instructions. Most notably, 16-bit push/pop take 2 bytes each, while their 32-bit counterparts take 4 (!) bytes each. And remember, these are the instructions that the GNU C compiler uses for passing all function arguments to vararg functions and all arguments (except the first 3) to other functions.

2. The H8S has an extensive set of instructions for operating upon bits, bit masks, etc., and these instructions have rather short opcodes. It is amazing what one can do with a carry bit. This is great for operating system (especially device driver) writers, and for die-hard assembler addicts. But from the compiler's perspective, they are almost useless, and simply eat up opcode space, making "useful" (from the compiler's point of view) opcodes much longer.

3. The H8S has a RISC-alike architecture in many respects. First and foremost, the lengths of all its opcodes are multiples of 2 (the length of a machine word). From the perspective of optimizing an opcode set in terms of average code length (by Hitachi engineers), this was a bad thing. RISC architecture also implies that, in any opcode, all involved registers must be denoted explicitly — all you can do with the memory operand is load or store it.

4. It seems that in the famous "time vs. space" tradeoff, Hitachi engineers have always favoured time. The most notable example is the execution flow control instruction subset. There are two "flavours" of most such opcodes: "branches" (opcode names are some derivations of 'branch', opcodes are 2-byte and employ 8-bit relative displacements) and "jumps" (derivations of 'jump', 4-byte, 24-bit displacements, respectively). The funny thing is that, while instructions must be aligned upon 2-byte (word) boundaries, "branch" opcodes address bytes, not words. That is, displacements stored within instructions never have its lower bit set. Even if you (via some cheating) store 1 there, it will be ignored by the internal processor logic. So why not store disp/2 and "expand" it (i.e. left-shift) just before utilization, enlarging byte-addressable range (and thus reducing the need for the dword-sized jumps) by a factor of two? It seems like this would require one extra processor cycle.

The features mentioned above are great if you're dealing with a controller, firmware for the "frozen" built-in system, or just something time-critical. But Cybiko features an extensive object-oriented OS (with pre-emptive multitasking), GUI, an extensive and ever-growing set of applications, and much more. And these features, and much more, must fit in only 250k RAM. So, we started looking for something less expensive in terms of consumed memory, and came up with our bytecode interpreter (which, BTW, currently uses only 950 bytes by itself!).

The above list could be expanded, of course, but there is also another big reason for implementing a bytecode interpreter, which can be explained in even greater detail. Fortunately, Sun Microsystems did the boring work for us by advertising their Java virtual machine with a bytecode interpreter of its own. So to learn more about the huge and undisputed advantages :-) of interpreted vs. native code, you're probably better off with Sun's The Java Language Environment: A White Paper (by James Gosling and Henry McGilton).

  .