This method of Jasmin code generation direct from a B module works well for simple examples. However, it quickly became unwieldy. Eventually, it was clear that this approach was not the best possible.
While it is basically straight-forward to add new support for additional OP-codes, the amount of work can still be large. For example, to add support for basic Perl tied variables, special Java classes would need to be developed that act much like the data structures internal to perl. While this can be done by reimplementing in Java what perl already does, such a task is quite complex, tedious and time-consuming.
In addition, emitting Jasmin assembler for even the most basic operations is tedious. For example, operations like simple conditionals needed to be carefully hand-coded and debugged. In the case of conditional statements, this work took days, and most of the work was simply finding bugs in the way Jasmin code was emitted. Compiler technology has really evolved to the point where such tedious work for code generation should not be done by hand. This fact hinted that the approach described here was flawed.
Yet, the worst problem encountered with this approach, and the one that finally made it completely clear that B::JVM::Jasmin was on the wrong path, was dealing with bytecode verification. This problem is exemplified best by the ``novel'' way B::JVM::Jasmin handled the PVM run-time stack. It seemed that the JVM operand stack could be used to emulate the operations of PVM run-time stack--using the JVM stack to hold the ``mark'' and those values to be later fed to LISTOPs like ``print''. However, when subject to bytecode verification, JVM code of this nature was rejected, since the verifier could not determine a constant limit on the stack (i.e., the verifier cannot solve the halting problem).
Quickly, it became clear that this direct compilation was not the best approach. Either much more of the system would need to be hand-coded in Java, or excessive care would need to be taken to ensure that no generated code could possibly upset the bytecode verification process. This issue, coupled with the sheer difficulty in doing such low-level code generation, led to a search for a new approach. That new approach was quickly discovered, and is discussed in the next chapter.
Copyright © 2000, 2001 Bradley M. Kuhn.
Verbatim copying and distribution of this entire thesis is permitted in any medium, provided this notice is preserved.