The ACK C compiler compiles programs written in C to EM, an intermediate code described in [ACK]. The back-end had to translate the EM code to Java bytecode. After studying the Java bytecode and the EM code it became clear that this was not possible. The problem was that the Java bytecode has typed instructions. This means that these instructions encode type information about the values they operate on. For example, the instruction to load the contents of an int variable onto the operand stack is the iload instruction. There also is a lload , a fload , a dload and an aload instruction for types long, float, double and reference respectively.
In the EM code there is no type information whatsoever, so mapping the EM instruction set to the JVM instruction set was doomed to fail. There is a code optimizer for EM code which tries to retrieve the types so it can do type specific code optimization, but it does not always succeed in the retrieval of those types. In that case it just gives up and just does not optimize that specific part of the code, so that is of no use to us.
So when there is no type information in the EM code, there is no back-end from EM to Java bytecode. The only other option was to change a specific front-end so that instead of generating EM code it generates Java bytecode.