assets/developer-notes/stephanie-gawroriski/2016/07/30.mkd

   1 # 2016/07/30
   2
   3 ## 00:42
   4
   5 There should probably be a limit of 65,536 strings in a single namespace.
   6
   7 ## 00:58
   8
   9 Seems no output ZIP is written, I suppose I have missed that.
  10
  11 ## 13:14
  12
  13 I would like TAS-support in emulators, but perhaps I am thinking too much into
  14 it. The emulator should be as simple as possible but good enough where it could
  15 run average programs that are not special in a way. Something I can do is make
  16 it where it can be handled like a normal Java method so to speak. So you can
  17 call main on a regular C method where it returns an `int`.
  18
  19 ## 13:37
  20
  21 Ok, so what I can use is a `DeviceManager` which manages classes which act as
  22 `BasicDevice`. Perhaps `AttachmentManager` might work better. Basically there
  23 would be a generic manager which has device groups such as block devices,
  24 virtual file systems, and other such things. When the emulator is initialized
  25 it can setup a given manager. I would then suppose that there would be emulator
  26 managed attachments and user managed ones.
  27
  28 ## 13:40
  29
  30 Emulators can have groups of processes so to speak and possibly switch between
  31 them manually or automatically. So what I need is essentially an interface
  32 that is used as a display output so to speak.
  33
  34 ## 15:49
  35
  36 I need a reverse resolution where I can open files and access them as blocks
  37 of data of sorts without having lookup each time.
  38
  39 ## 16:19
  40
  41 I should make it so the emulator can run another binary and not the one that is
  42 in the distributed ZIP and with custom arguments.
  43
  44 ## 16:28
  45
  46 Then this way, I can test arbitrary executables using the target emulation
  47 system without worrying about setting up another emulator interface.
  48
  49 ## 17:57
  50
  51 Much of the emulator logic will be very much the same between all targets, so
  52 I should just have a generic emulation method that just creates the emulator
  53 and performs any needed initialization, if it has been performed.
  54
  55 ## 17:59
  56
  57 However, the `TargetBuilder` is slightly ugly when it comes to the emulator, so
  58 I should make an entirely new class which can set it up and such.
  59
  60 ## 18:06
  61
  62 To handle various arguments that could be added in the future, the new class
  63 can just get a structure which holds variables. This could also support being
  64 auto-closed so that the ZIP can be opened also without much worry.
  65
  66 ## 18:19
  67
  68 This means `BuildConfig` can lose some things.
  69
  70 ## 19:10
  71
  72 I believe for all targets that I make, I will always go with static and just
  73 directly system call the kernel. Static executables are easier to make and
  74 everything is standalone, there should never be a library issue at all.
  75
  76 ## 19:13
  77
  78 I am going to actually need to write a filesystem path simulator setup (i.e.
  79 an emulated variant of `FileSystem`) for usage on the target system. This
  80 would be better than paths and such. I would suppose then that
  81 `EmulatedFileSystem` can be given mount points which point to something
  82 similar to the volume interfaces. Because messing with strings is going to be
  83 very very messy. However, there is essentially going to be duplicated code for
  84 the emulator and the real system. So not only would I need to write a path
  85 management system for the emulator but the target JVM running on real hardware
  86 too. The path management system does not need to worry about opening the files
  87 just handling the path information.
  88
  89 ## 20:07
  90
  91 Actually instead of an `EmulatedFileSystem` I can instead have the same for
  92 the path system and have there be an actual lighter and more generic class.
  93 The processes running on the JVM would then communicate with the processes.
  94 This then new `NativeFileSystem` could then also be used by the emulator. Since
  95 the code would essentially be written twice, however the emulator would use a
  96 slightly different way to access the actual data on the disk (or a virtual
  97 representation of it).
  98
  99 ## 20:12
 100
 101 I would suppose that this would be a class rather than an interface. Each
 102 file system would be bound to the native path system.
 103
 104 ## 20:15
 105
 106 Java SE uses `FileSystemProvider` to provide native stuff, while Java ME does
 107 not have this class.
 108
 109 ## 20:28
 110
 111 Thinking about it, some of the emulator code would also be shared with a
 112 hyper visor.
 113
 114 ## 20:31
 115
 116 Emulators are simple, but determining how to organize the code nicely can be
 117 a bit complex. Perhaps I am thinking too far into it. I suppose that the
 118 emulator should be as simple as possible. This means I would just have an
 119 emulator for example that emulates MIPS. These would just be `emulator-mips`
 120 and such. The `emulator` would just be a basic execute whatever it finds in
 121 memory emulator. Then the emulator would be able to be given a class which is
 122 basically a trap handler for a system. So say for example that MIPS code calls
 123 trap or an illegal instruction, when this occurs the interface will be called
 124 into. This would be how operating systems would be simulated. Then on top of
 125 the emulator would be the `HypoVisor` (pun intended). The hypovisor would
 126 basically be this interface. For emulation of systems, there would just be
 127 default ones such as ones for Linux which knows how to load binaries into
 128 memory and then set the associated CPU state for execution.
 129
 130 ## 21:50
 131
 132 This code seems much cleaner so far and also far simpler to setup.
 133
 134 ## 22:02
 135
 136 The ZIP block code never had a `size` method. Also reading a 1MiB entry from
 137 the ZIP all at once appears to be taking quite some time.
 138
 139 ## 22:05
 140
 141 After about 32KiB it just starts to get seemingly exponentially slower. So it
 142 is likely the inflate algorithm that is extremely slow after awhile.
 143
 144 ## 22:06
 145
 146 I am going to guess that it is the sliding byte window, since that has a size
 147 of 32KiB.
 148
 149 ## 22:08
 150
 151 And my intuition was correct, the code I have there works but is very slow.
 152 Even though it should be handled good enough using the dynamic window, I
 153 suppose that windows get created in a large number. I really just need a single
 154 dynamic buffer which acts as a ring buffer. Using it as a ring buffer would
 155 mean that after the allocations there will never need to be a removal.
 156
 157 ## 22:10
 158
 159 Also the bulk operations are not performed in bulk.
 160
 161 ## 22:11
 162
 163 Also appears the fragment size is 4.
 164
 165 ## 23:04
 166
 167 `SizeLimitedInputStream` could also potentially use a bulk read operation to
 168 speed things up also.
 169
 170 ## 23:08
 171
 172 Ok so now it does not get exponentially slower, it just remains slow now. So
 173 there is definitely a deficiency in the inflate code path somewhere. It appears
 174 the code is getting slower and slower a tiny bit each print iteration. So I
 175 would say that it is linearly getting slower.
 176
 177 ## 23:11
 178
 179 So the next thing I would say is to refactor `DynamicByteBuffer` so that it
 180 works better and is faster. Perhaps before that, support bulk get in `SLIS`. It
 181 is likely it is the dynamic buffer code because that is used in the inflate
 182 code I believe along with all of the data queues eventually.
 183