There should probably be a limit of 65,536 strings in a single namespace.


Seems no output ZIP is written, I suppose I have missed that.


I would like TAS-support in emulators, but perhaps I am thinking too much into it. The emulator should be as simple as possible but good enough where it could run average programs that are not special in a way. Something I can do is make it where it can be handled like a normal Java method so to speak. So you can call main on a regular C method where it returns an int.


Ok, so what I can use is a DeviceManager which manages classes which act as BasicDevice. Perhaps AttachmentManager might work better. Basically there would be a generic manager which has device groups such as block devices, virtual file systems, and other such things. When the emulator is initialized it can setup a given manager. I would then suppose that there would be emulator managed attachments and user managed ones.


Emulators can have groups of processes so to speak and possibly switch between them manually or automatically. So what I need is essentially an interface that is used as a display output so to speak.


I need a reverse resolution where I can open files and access them as blocks of data of sorts without having lookup each time.


I should make it so the emulator can run another binary and not the one that is in the distributed ZIP and with custom arguments.


Then this way, I can test arbitrary executables using the target emulation system without worrying about setting up another emulator interface.


Much of the emulator logic will be very much the same between all targets, so I should just have a generic emulation method that just creates the emulator and performs any needed initialization, if it has been performed.


However, the TargetBuilder is slightly ugly when it comes to the emulator, so I should make an entirely new class which can set it up and such.


To handle various arguments that could be added in the future, the new class can just get a structure which holds variables. This could also support being auto-closed so that the ZIP can be opened also without much worry.


This means BuildConfig can lose some things.


I believe for all targets that I make, I will always go with static and just directly system call the kernel. Static executables are easier to make and everything is standalone, there should never be a library issue at all.


I am going to actually need to write a filesystem path simulator setup (i.e. an emulated variant of FileSystem) for usage on the target system. This would be better than paths and such. I would suppose then that EmulatedFileSystem can be given mount points which point to something similar to the volume interfaces. Because messing with strings is going to be very very messy. However, there is essentially going to be duplicated code for the emulator and the real system. So not only would I need to write a path management system for the emulator but the target JVM running on real hardware too. The path management system does not need to worry about opening the files just handling the path information.


Actually instead of an EmulatedFileSystem I can instead have the same for the path system and have there be an actual lighter and more generic class. The processes running on the JVM would then communicate with the processes. This then new NativeFileSystem could then also be used by the emulator. Since the code would essentially be written twice, however the emulator would use a slightly different way to access the actual data on the disk (or a virtual representation of it).


I would suppose that this would be a class rather than an interface. Each file system would be bound to the native path system.


Java SE uses FileSystemProvider to provide native stuff, while Java ME does not have this class.


Thinking about it, some of the emulator code would also be shared with a hyper visor.


Emulators are simple, but determining how to organize the code nicely can be a bit complex. Perhaps I am thinking too far into it. I suppose that the emulator should be as simple as possible. This means I would just have an emulator for example that emulates MIPS. These would just be emulator-mips and such. The emulator would just be a basic execute whatever it finds in memory emulator. Then the emulator would be able to be given a class which is basically a trap handler for a system. So say for example that MIPS code calls trap or an illegal instruction, when this occurs the interface will be called into. This would be how operating systems would be simulated. Then on top of the emulator would be the HypoVisor (pun intended). The hypovisor would basically be this interface. For emulation of systems, there would just be default ones such as ones for Linux which knows how to load binaries into memory and then set the associated CPU state for execution.


This code seems much cleaner so far and also far simpler to setup.


The ZIP block code never had a size method. Also reading a 1MiB entry from the ZIP all at once appears to be taking quite some time.


After about 32KiB it just starts to get seemingly exponentially slower. So it is likely the inflate algorithm that is extremely slow after awhile.


I am going to guess that it is the sliding byte window, since that has a size of 32KiB.


And my intuition was correct, the code I have there works but is very slow. Even though it should be handled good enough using the dynamic window, I suppose that windows get created in a large number. I really just need a single dynamic buffer which acts as a ring buffer. Using it as a ring buffer would mean that after the allocations there will never need to be a removal.


Also the bulk operations are not performed in bulk.


Also appears the fragment size is 4.


SizeLimitedInputStream could also potentially use a bulk read operation to speed things up also.


Ok so now it does not get exponentially slower, it just remains slow now. So there is definitely a deficiency in the inflate code path somewhere. It appears the code is getting slower and slower a tiny bit each print iteration. So I would say that it is linearly getting slower.


So the next thing I would say is to refactor DynamicByteBuffer so that it works better and is faster. Perhaps before that, support bulk get in SLIS. It is likely it is the dynamic buffer code because that is used in the inflate code I believe along with all of the data queues eventually.