assets/developer-notes/stephanie-gawroriski/2014/11/13.mkd

   1 # 2014/11/13
   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 ## 15:10
  10
  11 Did not code earlier today, was helping out family, but I suppose it is good
  12 to get a break.
  13
  14 ## 16:34
  15
  16 Thinking about it, I have the ClassFile and all the associated info classes
  17 and such. However, right now what I have is taking the ClassFile and turning
  18 it into a Logical with MethodLogicals (and eventually FieldLogicals) of which
  19 are all the same thing. Well, the logicals would store a more descriptive form
  20 of a ClassFile. The normal ClassFile just contains a straight up
  21 representation of a class file as found on the disk. Although there are some
  22 doubts, I believe the logical stuff is the way to go. It might be simpler to
  23 make the class and methods that exist from the ClassFile (the snapClass)
  24 should be immutable. The ClassFile itself is not immutable, but if you take a
  25 logical class and mess around with it bad things can occur. So I suppose that
  26 every part of it should be immutable while the methods could be assigned new
  27 programs used during retranslation. It would also massivly simplify locks and
  28 such as I would not need to add locks all over the Logical stuff like I do
  29 with the ClassFile stuff. The ClassFile is meant for loading and generating of
  30 class files at runtime, while the logical is meant for compilation. The
  31 logical has to copy some of the class information so it becomes useful
  32 however, but it locks every aspect of it. So perhaps instead, I can have a
  33 MachineReader which reads some kind of input form (like Java byte code) and
  34 turns it into abstract language with trees and such. Then there will be a
  35 MachineWriter which then turns that abstract language into machine code (or
  36 byte code again). This way there is no real need to handle operands in Java
  37 byte code as much because they will be in a fully generic form (the abstract
  38 tree). My previous idea was to load the byte code (or some other machine code)
  39 and translate it into a representation of the native form. However that would
  40 add an extra step although it might not be fully easier. The abstract tree
  41 nodes could always have the original opcodes that they consist of. Then with
  42 the abstract tree it can be optimized then translated so that it best matches
  43 the target system. So the initial load of the Java byte code will result in
  44 very ugly abstract tree (since Java is pretty stack heavy, although local
  45 variables can be seen as registers). So the abstract form will consist of
  46 stack operations and "register" operations. The optimizer would then remove
  47 all stack based operations and have it be performed completely in registers
  48 (since those are the best), while solving other issues like math and such.
  49 Other translations such as removing method calls to certain classes (such as
  50 Math, String, Atomic classes, Locks, and some others).
  51