09:24
So I will need to fix all of the version information and figure out a way to implement standard liblet descriptions. This would be for standard functionality dependencies. However I cannot find any property which describes which standard something implements.
09:44
I suppose for other versions and such, I will just use a kind of release
system I suppose. I would say that I will start at 0.0.0. Once SquirrelJME
is 100% compatible, this will become 1.0.0. Minor versions in development
will be even numbers such as 0, 2, 4. Although in this case I would ever only
be able to perform 49 releases. So I suppose I will do this at the micro
scale. So initially I will start at 0.0.2 so that it is not zero.
11:42
Something that could work is if there is no line based interface possible and no graphical interface possible, that there could also be a standard I/O based interface. If it could support non-blocking read/write (so stuff can run in the background in a cooperative-like manner) or has blocking read/write. In the event of blocking, I may just have to have a continue command to continue execution, unless interruption can be detected in which a prompt will appear and block. So basically...
- If non-blocking stdin can be read, then input commands can be read without blocking running programs.
- If interrupts are supported then interrupting will go to a prompt.
- If threads can run in the background, everything would be preemptive.
- If threads cannot run in the background, continuation would be required before execution continues.
- If stdin blocks and there is no means of interruption then after a certain point a prompt will appear waiting for a continue unless something requires some kind of input.
12:14
So what I need is namespace output.
13:44
I would suppose I would need a JIT that is traditional for traditional CPUs. These would be how CPUs for the past few decades have operated. This would be nothing non-standard such as esoteric systems or programming languages.
17:46
I would suppose that I could also have a traditional namespace writer also for specific systems too. Generally all of them will follow the same layout at least (a bunch of machine code, some tables, etc.). Anything esoteric would completely not fit at all. It would likely be best if the blobs for each and every architecture were exactly the same.
18:28
Having the cache output stream created in the namespace processor does not make any sense. It should instead be created in the namespace writer if a file on the disk was requested.
19:00
I also have the option of JITting to something that is not a CPU but a language. I could compile to Javascript but handling of binary files really depends on the browser it is running on. Alternatively I can target POSIX shell (which would produce very slow code) or other languages such as Python (despite not knowing it). I could also target the JVM. Although for the JVM, entire namespaces are likely to not fit within a single class file. This would put a limit of 65534 unique constants with 65536 fields and 65536 methods. Each namespace would pretty much have to be written to a JAR in a JIT like manner that allows for individual VM instances to exist. This would mean that all methods would essentially be static (since instances would not make as much sense). Objects passed around would be virtual object representations. Every method would have to have as a first parameter, a virtual machine interface of sorts. So targetting Java would be a bit feasible. At least stuff such as primitive types can be passed around as-is. However, all objects would be passed with a virtual object representation for the most part. Then since linear ZIPs are supported (similar to TAR archives) I can output a JAR like this, then at the end write the complete entry table. Since I lack an inflate compression algorithm, the data would essentially be stored. There then could be a stubbed code that acts as the virtual machine. It would setup some initial objects and then just call the JITted code.
19:10
The only consideration would be exception handling, would I have actual
handling of exceptions or virtualized exception handling (a switch with a bunch
of goto operations). This would be a rather complex first step however. I could
have an output which generates C source code however. The OutputStream cache
form would essentially be a TAR archive containing C source and header files.
Header files would be last, then using preprocessor magic the normal code
generation can occur.
19:36
I suppose I can develop the JIT compiler by outputting to standard C code.
19:50
Then at least with C code, if the JIT compiler starts getting a bit ugly I can drop some things. Basically this compiler at first would have the potential for refactoring and being tossed out. I can just use a pre-existing compiler such as GCC to compile the C code and manually test if it works. Then I can have more flexibility.
19:59
So yes, I shall work on a C code generator and ignore PowerPC on Linux for a bit. Then once I have the interfaces required for code generation I can more easily fit the PowerPC generator into it.
20:58
I suppose when it comes to languages the architecture will just be language,
the variant will be generic, the operating system will be the target
language. The operating system variant would just be generic.