SquirrelJME/SquirrelJME

# 2016/02/26

## 10:18

This is my start of SquirrelJME which is similar to SquirrnixME except it is
under the AGPLv3+ and has pretty much the same intended goals.

## 13:39

For specific systems I am going to need to use `near`, `far`, and such. For
example the Zilog Z80 compiler uses `near`, `far`, and `rom`. `rom` addresses
the built in memory since normally the hardware does not have a unified address
space for accessing read-only data and in memory data.

## 16:56

Going to need style guidelines so things are cross platform and such.

## 20:53

It might be more interesting to have this code and such be in pure Java,
except that a front end is used of sorts to generate code for the target
system. But then this would be Squirrnix all over again. This would however
be far lighter and I could probably get away with simplification. Otherwise in
general it would help with learning to write a basic compiler (from Java byte
code to machine code). As for cross platform support (such as Linux, Palm OS,
Amiga, etc.) I can have it be self hosting so to speak, so that the compiler
generates all the code for the given targets. So basically this will be a
mini sized Java ME environment writting in itself. One thing I will have to do
however is make sure all my code can run on its own environment. However, in
these cases I would not have to worry about C language details at all. It would
also probably be much simpler too. I could build essentially a basic mini IDE
of sorts to run and test code, which would be interesting too. Due to the way
the Java ME virtual machine laid out, there is no invokedynamic and the code
will essentially require at minimum a Java 5 implementation. However thinking
more into it, I could reuse the internal compiler and have it used as a JIT so
code can be dynamically compiled and ran. If a JIT is not requested then
instead only an interpreter would be available. Then I can have stuff such as
exceptions and whatnot without worrying too much about things. I do however
have to have an SDK to compile against to be sure of compliance. However in
general I can run the code on the host virtual machine provided I am careful
of the APIs I choose (Java ME has a few extra methods that Java SE does not
have).

## 21:00

Another advantage of being in pure Java would be that I would not need a C
compiler at all for various systems. However, if a system cannot run any Java
virtual machine at all, then a cross compiler with itself would be built. I
suppose this would be kind of similar to Free Pascal except all targets could
be supported and included. One thing I do not have to worry about is standard
system libraries, I can use what I need instead of bringing in massive APIs
and such. Then whatever I learn from this (because it will be much lighter and
such) I can bring to Squirrnix and continue that compilation system. So
effectively Squirrnix will be partly based on this environment. I suppose for
starts I should start small doing this.

## 23:33

Actually, what I will need is ZIP file handling and decompression support.
Otherwise without this, I cannot read JARs. However since I do not need
compatibility with the standard library, I do not need to go crazy over
compatibility for it. I suppose that virtualized access to memory is done by
a `SeekableByteStream` for example. This way if a JAR is in a `FileChannel` or
is in the ROM it can be used regardless of its location.