The goal of the project was now to change the ACK C front-end so that instead of generating EM code it generates Java bytecode. This was not possible because of yet another problem: There is no way of doing pointer arithmetic in the Java bytecode.
Because there are no pointers in Java or in the bytecode, only references to objects, pointers have to be simulated by those references. The problem with this is that there is no way to know the address of an object in the Java bytecode. The only thing you know is that the space needed for the object is allocated from the heap, and that there is a reference pointing to it. There is no way to get the address of the object in the heap, and so there is no way to manipulate the address of the object. The references to objects are of type reference, which means that they can not be loaded with, for example, an instruction to load an integer, and so there is no way to do any arithmetic with the reference. In C you can just about do anything with addresses of variables and constants, so compiling C directly to Java bytecode was going to be a problem.
A way to solve this problem was to simulate your own memory in the Java bytecode in which you do all the allocating and freeing yourself, but that would mean that you would create your own instructions for allocating and freeing memory and for loading and storing values. This way there would not be a lot of real JVM instructions left to use, and you take away the whole essence of compiling something to Java bytecode that is not meant for it and using the instructions for things they are not made for.