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

   1 # 2014/11/17
   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:06
  10
  11 Well I have opcodes loading (Java byte code that is), but I seem to be stuck
  12 on tableswitch and lookup switch. The read values should be 1 to 12, however
  13 the count is read wrong.
  14
  15 ## 15:16
  16
  17 Actually it would be the padding, because I was doing it based on the start of
  18 the Code attribute where the padding is just done from the start of the actual
  19 byte code. And now it all works. Yipee.
  20
  21 ## 17:46
  22
  23 Arguments being their own type of zone will simplify things because although
  24 Java has a mistakingly long and double taking up two local slots, mine is
  25 fully logical and they take up one slot no matter how much memory is to be
  26 represented. So the stuff is quite literally just variables. However, at the
  27 start of the SSA form of the method the arguments will be copied to locals so
  28 the later conversion handler correctly sees the initial results as needed. The
  29 generator from raw op codes to SSA op sets will need information passed to it
  30 from the language form information, otherwise some important information may
  31 be lost.
  32
  33 ## 20:24
  34
  35 I need an efficient way to represent operations in a sort of immutable sense.
  36 Would require duplication but immutibility has some proofs in that it can be
  37 accessed by many things at once. Well MethodPrograms see the stuff as being
  38 immutable (since they use unmodifiable lists).
  39
  40 ## 20:30
  41
  42 Actually the MethodProgram taking the lists and setting up an internally non-
  43 modifiable bit is rather bad. The MethodProgram also has the language form
  44 specified but SSA is not language specific. Perhaps something that would be
  45 better and faster is instead of running through getting all the raw opcodes
  46 first and then generating SSAs from them would be to do it all at once in a
  47 single pass rather than 3. Because currently the order is this: decode raw
  48 operations to a raw list, go through list and generate SSA operations, (then
  49 eventually) optimize the SSA to a generic form. However, using a builder with
  50 just an add operation, the MethodProgram can handle parrallelization of
  51 programs rather simply. If the next operand does not rely on the state of a
  52 register at the current level it is attached to, however if not it is then
  53 added to a new level. Then forking can be done, a state can be saved and a
  54 path taken based on a specific condition (comparison of a register to another
  55 or a constant). Then this ProgramBuilder takes care of the optimization and
  56 generalization of things. So while the SSA operations are being added it can
  57 just prune stuff as needed. So if something sets the same value to a known
  58 value twice (and it is not a (volatile) field access) then it can just remove
  59 the operation as it is pointless anyway. However for clarity, when there are
  60 exceptional bounds they cannot be parrallel because if an add operation and
  61 another operation can normally be parallelized but one is in an exception
  62 block then it cannot be parallelized. So there would need to be
  63 synchronization and exception subzones. And doing it this way (with a builder)
  64 will make it so simple first stage optimization may be performed. Another
  65 thing that can be done is semi-conditionals. For each set, only act on it if a
  66 specific operation is a success. Although that may be a bit complex to work
  67 out. Rather than that it might be better to just fork as needed. Although the
  68 byte code interpreter would have to be capable of handling forks as needed.
  69
  70 ## 23:00
  71
  72 I know one important thing I will need in the kernel, all of the recompilation
  73 stuff done through the code I am doing now must be part of another process.
  74 That way when compilation is done it can just be trashed completely so that
  75 memory is not wasted, however that might not even be needed at all. Depends on
  76 the memory situation. Going to try out NetBeans, maybe it will work better
  77 than IntelliJ and not be completely messed up on my super strange JamVM
  78 PowerPC OpenJDK 8 system. We shall see about that though.
  79
  80 ## 23:13
  81
  82 Quite a bit sluggish at least first time in the options dialog, but I am using
  83 an interpreter. I do like the stylish Metal UI, better than that InteliJ theme
  84 junk. I dislike the connect to internet start page, which hopefully can be
  85 disabled. Spams "jmm_DumpThreads" to the console though. It is using up all of
  86 the CPU currently doing something unknown. This might be why it is slow, it
  87 was launched with "-client" and that is the by default super slow JVM.
  88
  89 ## 23:52
  90
  91 Have my settings configured now, hopefully it does not trash my files.
  92