Boxed value caching, for memory saving can be done with linked lists essentially although valueOf lookup would be very slow. It might be best to not cache at all.


I need a faster huffman lookup code, since that is quite slowing down my build much (since I need to decompress the ZIP files). If I make the huffman lookup fast then it should compile much faster. I devised my own seemingly good speed huffman lookup using remaining bits and such, on my markerboard. With a random huffman tree that I setup, each resulting value ends up being in a single index.


So I need to figure out what is wrong with my ELF and why it says "Invalid Argument".


Unless, a program header of zero is considered invalid, but other binaries use the zero program header. Unless I absolutely need a data section.


However, removing the data section of a binary makes it still work (although in the practice binary no text is printed).


Looks like QEMU fails in load_elf_interp. However my binary does not have an interpreter because it is static. Also looks like the ELF is completely corrupted too. But that structure is not initialized. So either elf_check_ident fails or elf_check_ehdr does.


So now I built a debug version of QEMU.


Looks like it fails because the host page alignment is not correct, right now the alignment is just zero so perhaps if it were made to be 4K.


I am actually going to need a better ELF writing class, with perhaps a builder since there can be a large number of differences between different systems which use ELF. I suppose the best thing to do would be to make it object oriented so I can declare what I need.


Looks like the end address Entry point address: 0x444cd0 is not valid. And I hope it will work now.


Now it says invalid argument.


Appears that QEMU (and I suppose) Linux are trying to directly memory map the ELF binary. Since the offset in the file is not meeting the target page mask, it fails to load properly. However in the hello binaries there are:

[ 3] .text        PROGBITS        00400018 001018 000020 00  AX  0   0  4
[ 2] .text        PROGBITS        004000b0 0000b0 000020 00  AX  0   0 16

In the second case 0xb0 can be divided by 16. Also appears the target page bits in QEMU MIPS is 12-bits.


Actualy sections are pointless. The hello worlds have:

LOAD           0x001000 0x00400000 0x00400000 0x00038 0x00038 R E 0x1000
LOAD           0x000000 0x00400000 0x00400000 0x000d0 0x000d0 R E 0x10000

While mine has:

LOAD           0x0000d8 0x00400000 0x00000000 0x44cd4 0x44cd4 R E 0x1000

So this means that the offset in the file has to match the alignment. So in short I need a new and better ELF writer. The ELF writer has to be rewritten anyway to be much better, because currently this is not going to work. SquirrelJME is also a bit large at around 275KiB without any code. I can see it becoming about 1MiB with everything. This is just an initial target however. Eventually a new output could be generated which likely uses less size. But also consider that the extra space is consumed by resources. So if entries were to be deflated the binaries would be much smaller too. In the end, I would deflate entries anyway.


First, ExecutableOutput needs to lose the linking, where it completely becomes implementation dependent on what is done.