00:42
There should probably be a limit of 65,536 strings in a single namespace.
00:58
Seems no output ZIP is written, I suppose I have missed that.
13:14
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.
13:37
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.
13:40
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.
15:49
I need a reverse resolution where I can open files and access them as blocks of data of sorts without having lookup each time.
16:19
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.
16:28
Then this way, I can test arbitrary executables using the target emulation system without worrying about setting up another emulator interface.
17:57
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.
17:59
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.
18:06
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.
18:19
This means BuildConfig can lose some things.
19:10
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.
19:13
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.
20:07
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).
20:12
I would suppose that this would be a class rather than an interface. Each file system would be bound to the native path system.
20:15
Java SE uses FileSystemProvider to provide native stuff, while Java ME does
not have this class.
20:28
Thinking about it, some of the emulator code would also be shared with a hyper visor.
20:31
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.
21:50
This code seems much cleaner so far and also far simpler to setup.
22:02
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.
22:05
After about 32KiB it just starts to get seemingly exponentially slower. So it is likely the inflate algorithm that is extremely slow after awhile.
22:06
I am going to guess that it is the sliding byte window, since that has a size of 32KiB.
22:08
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.
22:10
Also the bulk operations are not performed in bulk.
22:11
Also appears the fragment size is 4.
23:04
SizeLimitedInputStream could also potentially use a bulk read operation to
speed things up also.
23:08
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.
23:11
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.