So now the emulator.


So what I need is a filesystem for the most part, or at least a source of files.


So that would be basing off NativeFileSystem at least what the emulator will use. So I need perhaps emulator specific volumes. Although one thing I can do to reuse code is have an abstract filesystem that is completely virtual for the most part. File access and roots can be handled by classes using it. I can make this code not use anything that has a part of the emulator so that it can be reused by SquirrelJME outside of it. So this would be in effect a completely virtual filesystem.


The emulator could have a virtual ZIP file source, probably as another file. Essentially it would be one that uses the ZIP code.


One thing I must determine though is how I want to setup the VFS.


It may actually be more efficient to calculate the jump targets of the byte code and then pass that information to the method writer so it only has to keep a specific amount of state for jump targets.


So register allocation is simple, I just need a simple way to store the states. One thing though is that locals and stack item sizes are known in methods and I only need to store state for all of those locals. So I will need to pass the number of locals and stack items as Java sees it to the JIT.


And writing this, I got deja vu, in fact double deja vu.


I am actually going to need a complex multi-queue. Basically it is like a Deque except that it can have multiple queues in it that obtain stuff from the same source. Basically the class would be a MultiSetDeque in that an object could only be stored in a queue at once, but there could be multiple internal queues. This can be done with wrapping Deque and using a Set. When something is polled from the queue, if it is not in the Set then it is removed and forgotten about. I will need this for the register allocator because I need separated int and float registers to grab from, but for example in MMIX float and int are stored in the same registers. As such I would need to remove and/or split registers between dedicated integer ones and float ones, which would very much waste them.


I do need it to be four of them, for saved and unsaved ones for both int and float types.


I should sign my commits.


One thing to consider is what happens when clear is called on one of the sub-deques.


One thing I can do for simplicity although it could be complicated is that if software float is detected it can automatically change the floating point types accordingly before passing it to the actual JIT implementation. So in short, the JIT if it sees software float being used it will handle that.


I need a kind of storage for values. Essentially for local and stack variables.


Testing GPG a bit more.


And another test.


I could always in a way initialize an initial state with GenericAlloctorState and use that for storing things. However with that I will need to know which registers are available in the queue and which ones are bound in places.


When it comes to objects, I do not actually have to skip anything because on 64-bit systems a single register will store a pointer. I just need to consider the stack when it comes to objects.