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

   1 # 2016/01/19
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 09:40
  10
  11 Still very cold.
  12
  13 ## 10:08
  14
  15 Actually having a dedicated class for instructions for the ArchitectureData
  16 and one for registers can have it more easily cached. I can then just reference
  17 that instead. They can be a type of map however.
  18
  19 ## 10:21
  20
  21 What I can do is modify the Disassembler, Assembler, and MutableOpCode to use
  22 a future moved DataAccessor (I would have to move it out of kernel-bin) and
  23 then use that for placing instructions and decoding them. So for example
  24 instead of having MutableOpCode return a byte array to later be placed in, it
  25 could just write it directly so to speak.
  26
  27 ## 10:26
  28
  29 Then from the `InstructionMap` class I can have disassembler ready information
  30 such as images and mappings so that they can be decoded as required a bit
  31 faster and having it cached so it can be collected when it is no longer
  32 referenced. So I believe the first thing to do is move and cleanup (split off
  33 the DataStream) `DataAccessor`. Then I can engineer the Assembler/Disassembler
  34 around that along with MutableOpCode. I also wonder if I can have a
  35 disassembler view of an operating similar to `MutableOpCode` but is derived
  36 from the DataAccessor. When disassembling, if an operation is mutable might
  37 not matter, there also is a full copy which is required when changing it. I
  38 can also potentially handle something similar in the assembler. However
  39 thinking about this, it is possible to have a single stream for both the
  40 assembler and disassembler. So it would essentially combine both and allow it
  41 to be modified (if it can be written to). It could be a moving window view so
  42 that stuff can be shared.
  43
  44 ## 11:26
  45
  46 Ok, so the first thing to do would be to move the `DataAccessor` out and into
  47 its own project. Then I can also have a `GrowableByteArrayAccessor` which is
  48 essentially a byte array backed accessor which can increase linearly in size
  49 as instructions are output via the assembler.
  50
  51 ## 13:12
  52
  53 Figured out a name, I can just have it be `BinaryBlob` since that fits well
  54 as a better name than `DataAccessor`.
  55
  56 ## 13:48
  57
  58 Right now `BinaryBlob` like `DataAccessor` is limited to 2GiB, I should perhaps
  59 remove that limit so that there is more utility to the classes.
  60
  61 ## 17:08
  62
  63 ArchitectureData can probably go best without guessInstruction and instead make
  64 that part of the disassembler so that it only contains data and does not have
  65 any actual decoding logic.
  66
  67 ## 17:12
  68
  69 I wonder if there is a type of hash sum for very small potential values. I can
  70 do a linear search through the instruction table when disassembling, however
  71 that would be a bit costly. I can architecture specific lookups however there
  72 can be on the order of tons of instructions in how they are handled for each
  73 architecture. So what I can do is instead in the architecture manifest is to
  74 have a major op specifier of sorts which identifies the mask of the input
  75 bytes which define the instruction image in general.
  76
  77 ## 17:21
  78
  79 Well, I can have a merged assembler and disassembler (which would be quite
  80 powerful) so that there would instead just be a single class which does both.
  81
  82 ## 17:23
  83
  84 The class would essentially edit programs, so perhaps `ProgramEditor`. I would
  85 have to potentially support going back and forth between it or have unified
  86 positions and such. Also the `MutableOpCode.Value` could be wholly cached and
  87 such so that once the instruction is determined it can create values as they
  88 are needed rather than all the time. So the instruction could be guessed
  89 without the creation of any value fields in the map. Then if the fields of
  90 the instruction are cared about then they can be stored in a kind of reference
  91 map which can share the field mapping values. So essentially the value for
  92 field #3 in an instruction, if the instruction is changed then that field
  93 association (which bits it maps to and how) will be different. So storing the
  94 values as a kind of cache would be invalid. However, in short, the fields
  95 would likely be sorted by shift order so that way only a handful of fields are
  96 needed at once in memory. Essentially, the new `Value` for a field would end
  97 up being mapped to the field number. Any interaction with field values can
  98 just do something similar to `MutableOpCode` where they directly modify the
  99 bits of the program. The assembler could also support a re-interpret which
 100 forces the fields to be interpreted as another operation when it really is not
 101 that operation. What this means is that the _op_ field for **aaload** for
 102 example when the instruction is reinterpreted to **aastore** will still use the
 103 _op_ value as it would be for **aaload**. However for some instructions such
 104 as the wide variants, the fields are mapped to shift values so that the narrow
 105 version will probably start at byte 1, the wide value field will then be mapped
 106 to byte 2.
 107
 108 ## 17:31
 109
 110 Then MutableOpCode could still be used, but it would essentially just be a
 111 `ProgramEditor` with a semi-fixed position. However thinking about it, some
 112 architectures (such as Java byte code) may have specific alignment requirements
 113 for instructtions depending on the position of the instruction in the program.
 114 So these special instructions would appear wider and narrower depending on
 115 their position. There are also variable sized instructions. Fields could be
 116 generated based on this. The only use of `MutableOpCode` outside of the
 117 assembler and disassembler is to store a working operation before it is passed
 118 to the assembler. The disassembler loads into it, but the editor could just
 119 then have a nextInstruction(). I could have something similar to a queue where
 120 having `putInstruction` writes an instruction and then moves past it, while
 121 having an `offerInstruction` being similar to a put but without moving. The
 122 same could be said for disassembling where there are `poll` and `peek`.
 123 Going backwards in a program would be tricky however because previous bytes of
 124 a program may have changed. But when implementing it I shall figure out the
 125 true and better names to use than the ones named similar to queue.
 126
 127 ## 21:13
 128
 129 Was attacked by a dog today, it was biting my right wrist. Luckily for me due
 130 to the cold weather I was wearing a thick coat so my skin was undamaged. I
 131 would suppose that this drives me more to never want any pets at all. Was a
 132 rather horrifying experience. If my wrist were to be badly damaged then I
 133 would be unable to type as fast as I do and would probably have to do it one
 134 handed which would severely cut my speed while programming. However I would
 135 probably adept by switching to an editor where I can use lots of macros.
 136
 137 ## 21:16
 138
 139 However, I will calm myself by writing the `ProgramEditor` and watching some
 140 videos since I rarely watch videos.
 141
 142 ## 22:02
 143
 144 Just tired and out of mind, cannot really think about programming.
 145