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

   1 # 2016/01/08
   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 ## 07:26
  10
  11 Today I woke up early before the sun rise, which has yet to appear above the
  12 mountains and leafless trees for me. The clouds reflecting off the top are
  13 an interesting red. But a bright beam will be very noticable when it starts
  14 moving down on my walls.
  15
  16 ## 07:41
  17
  18 Thinking about this, I currently operate with a patch. I believe what I should
  19 do instead is have a from which is any binary type and then a to which is a
  20 patch type.
  21
  22 ## 07:55
  23
  24 That may result in faster getting a kernel compiled because I may not have to
  25 implment all of the patch stuff yet. Although on writing I will have to
  26 implement it all, so this is just a defer. However by not using a patch as
  27 a basis and having a target I can instead make processing a bit faster because
  28 then the constant pool and reference table will not require copying and such.
  29
  30 ## 08:28
  31
  32 I can also have a single class which contains input and output along with the
  33 configuration used for dynamic recompilation.
  34
  35 ## 08:30
  36
  37 The thing however, is what to call this new class.
  38
  39 ## 08:33
  40
  41 It is not a configuration, but it stores one and has input and output. It is
  42 a result but it is also input. Perhaps a State could work, then I could also
  43 have a kind of flag indicating what the recompiler is doing if possible, or
  44 a progress meter (if supported). Then classes which call the dynamic recompiler
  45 code can be told how far along recompilation is.
  46
  47 ## 08:50
  48
  49 Primaries might be a bad choice, but individual classes would be best.
  50
  51 ## 15:53
  52
  53 Forgot about equals and hash code for all the references.
  54
  55 ## 16:12
  56
  57 And for the constant pool entries also. Also realized that using a special
  58 tag type for null references I can now have references to null entries despite
  59 that probably not being very useful.
  60
  61 ## 16:24
  62
  63 Also in the constant stuff, not using `DescriptorClassName` and instead using
  64 the derived `DescriptorField` will result in potentially less bugs because
  65 `DescriptorBinaryName` and `DescriptorField` do not compare.
  66
  67 ## 17:20
  68
  69 This will be a problem with the way my patch stuff is setup:
  70
  71         net.multiphasicapps.k8.bin.patch.PatchCodeRef.getSlot
  72         net.multiphasicapps.poit.std.StandardRISCTranslator.loadCodeRefPointer
  73
  74 I should probably just remove the getSlot because that can be tricky to
  75 implement.
  76
  77 ## 17:27
  78
  79 I can use a cache of code references, assuming one does not modify a class
  80 while it is being recompiled, but that is undefined anyway.
  81
  82 ## 17:32
  83
  84 I wonder if I should make a distinction with the native CPU size and the size
  85 of a pointer. That could complicate memory models and such however it would
  86 mean that for 64-bit systems I can use less memory because pointers would
  87 be 32-bit. 64-bit arithmetic would see a boost, however it would affect all
  88 software because it uses the same dynamic recompiler. For system calls however
  89 I would have to be able to handle that although there is a bunch of base stuff
  90 in Object's code that uses long regardless.
  91
  92 ## 17:51
  93
  94 So right now I have two choices, I can keep all the compiled classes in memory
  95 or I can just store them to the disk and never reference them (so they
  96 eventually get garbage collected).
  97
  98 ## 22:16
  99
 100 The KBF handling is going to have to be refactored because right now the code
 101 is really ugly. It may be possible for the data to be shared between the
 102 reader and the writer.
 103