assets/developer-notes/stephanie-gawroriski/2016/08/01.mkd

   1 # 2016/08/01
   2
   3 ## 07:25
   4
   5 A new month.
   6
   7 ## 10:07
   8
   9 Ok, so I made 785 commits. I mostly just did JIT work last month. I wrote a
  10 JIT then got rid of it and rewrote it number of times. Currently the JIT how
  11 it is now is how I would like to continue with it. The same goes for the
  12 emulation system that I have planned. I just need to finish the refactoring of
  13 the dynamic byte buffer (by using partitions) and potentially speed up the
  14 sliding byte window class and support bulk read operations (since calling
  15 `read` over and over is slow). I added mirrors to other sites (using Git). I
  16 wrote ZIP reading and writing stream code. I will have to refactor the block
  17 based reader because the current one is quite bad and is pretty slow. I did
  18 a refactor of the test system since it was untouched for a few months. The
  19 current test system is quite nice and works out quite well. I also switched to
  20 the GPLv3 from the AGPLv3, this is more permissive as the AGPLv3 would
  21 complicate things when it comes to client browsers. I implemented the CRC32
  22 algorithm so ZIP entries can be checked and such. I added the base for the
  23 current JIT. Removed a bunch of old code. I also converted the mascot to SVG.
  24 So pretty much the main work that was done was in the JIT area.
  25
  26 ## 10:11
  27
  28 So my current goal is to finish the refactor of the supporting classes then
  29 move back to the JIT and generate Linux MIPS binaries instead. Going straight
  30 for a real target will allow me to test the MIPS execution system and the
  31 base emulation. So in reality I am dropping the interpreter. Going the
  32 interpreter route as I planned before would just be more difficult since the
  33 target system does not exist, I will need to invent an ABI for it.
  34
  35 ## 20:16
  36
  37 Did not do much at all today. What I can do for chunks so that they are not
  38 full of large partition tables, is to split each chunk into a fixed number of
  39 partitions and use those accordingly. Alternatively instead of having chunks,
  40 they can just really contain raw data so to speak. For example, a chunk can
  41 have no means of knowing where it is located, the dynamic buffer then just
  42 manages partitions that can point to various chunks. Perhaps I am thinking too
  43 much into it. Perhaps instead, chunks are statically sized. Each chunk is
  44 given a byte array, offset, and length. When a byte is removed from a chunk
  45 it is then split into two chunks (where the offset and length are adjusted
  46 accordingly, although they refer to the same array). Chunks could end up being
  47 split more as bytes are removed. However, if a byte being removed is at the
  48 end then the head/tail are just changed accordingly. The same would be true
  49 for insertion operations. This way when a chunk is split it only requires that
  50 the offset and length are changed. However do I make this information volatile
  51 or final? Going the volatile route would only require one extra allocation and
  52 a single insertion into the chunk list. It would also be easier as new
  53 references will not have to be managed after a split.
  54
  55 ## 20:29
  56
  57 For some simplicity, I can have the head/tail position value inside of the
  58 chunk individually. One thing to consider would be locating a chunk for a given
  59 position. Having the positions recalculated every time a byte is written will
  60 be extremely slow. So I will need a back chain of positions and staleness. If
  61 a chunk is stale then its position is not valid. However a chunk which is
  62 stale at the current position needs to make all other chunks after it also
  63 stale. Doing a recursive stale check will not be very fast on every operation.
  64 So I propose an instead, stale after chunk index kind of thing. Basically if
  65 a position is requested and the chunk is after the stale base, then it will
  66 go to previous chunks before the stale base and calculate the position. Then
  67 this way simply adding bytes at the end will not require mass recalculation
  68 if it is easy to solve.
  69
  70 ## 21:35
  71
  72 When all the bytes within a chunk are removed, then the chunk can be removed
  73 itself.
  74