assets/developer-notes/stephanie-gawroriski/2016/06/22.mkd

   1 # 2016/06/22
   2
   3 ## 08:39
   4
   5 The operations will need a list of externals that it accesses.
   6
   7 ## 08:41
   8
   9 What could help is a raw operation map which just has the operation code and
  10 the input values passed to it.
  11
  12 ## 08:45
  13
  14 Then I can use interpretations of the raw argument data with a kind of data
  15 interpreter.
  16
  17 ## 11:36
  18
  19 I can switch the explicit verification states to use an array where the states
  20 are binary searched instead of using a map.
  21
  22 ## 13:56
  23
  24 Perhaps what I can use in the byte code is some kind of pseudo operation
  25 definition of sorts. What really is needed though for the operations is just
  26 the logic that states how it modifies the stack, if it accesses any local
  27 variables, and other things.
  28
  29 ## 13:59
  30
  31 So it would basically be a micro operation that defines what a byte code
  32 instruction does. The compiler could actually in a way optimize a program
  33 based on the micro operations rather than the whole operations.
  34
  35 ## 14:02
  36
  37 Then stack verification would use the microoperations to determine the input
  38 and output state. An interpreter could also be purely based on the more simpler
  39 micro operations also.
  40
  41 ## 17:22
  42
  43 I suppose for micro operations, object would be used instead of integer
  44 values since that would be a bit more expressive.
  45
  46 ## 17:25
  47
  48 Alternatively instead of micro operations, there are instead micro-executions.
  49 If a concrete representitive form is needed then that can always be created
  50 from the executions.
  51
  52 ## 18:52
  53
  54 One thing to consider however are conditional operations. I suppose I should
  55 have explicit jumps at the end of every operation that points to the
  56 instruction that should be jumped to unconditionally. So after the bulk of
  57 instructions, there will just be an unconditional jump to the next instruction.
  58 This could then be used to build a tree or some other structure used by the
  59 compiler to determine how the program flows for potential optimization. Also
  60 the micro-executions should make native code generation simpler.
  61
  62 ## 20:20
  63
  64 Something which I can use are co-dependencies in a way. Have it so I can have
  65 the binary sort code in another package along with the SquirrelJME JVM specific
  66 classes. This way javame-cldc-compact can be kept clear of SquirrelJME specific
  67 classes.
  68
  69 ## 20:27
  70
  71 Actually before I do that, I should have a new build system of sorts which
  72 uses code that exists in the project directory as a kind of bootstrap of sorts.
  73 When it comes to the compiler, I can use `-implicit:none` so that classes
  74 which are co-dependencies do not get class files generated in the output. Then
  75 this way I can have source code depend on each other as such yet not require
  76 a special algorithm be used to filter out co-dependencies.
  77
  78 ## 20:35
  79
  80 I can also then have a generic build interface that can be given an interface
  81 which can be used with a compiler or run-time system. In the event such a
  82 system would run on SquirrelJME itself the interface will instead map to a Java
  83 compiler which I have written along with an interpreter. Then this way, a build
  84 system can be shared inside and outside of SquirrelJME.
  85
  86 ## 20:37
  87
  88 Also, I likely do not need to prefix my packages with `squirreljme` since this
  89 is SquirrelJME.
  90
  91 ## 21:02
  92
  93 Doing a refactor of the source code layout and packages that code exists in.
  94 One thing I can do is remove all of the `extra` before the io and util
  95 packages.
  96
  97 ## 22:31
  98
  99 Also, the `javame` prefix could be removed also.
 100
 101 ## 22:48
 102
 103 I should and must have a base class for SquirrelJME itself, then the PVM JVM
 104 can be based on that class. Initialization code and other things could be
 105 shared and as such it would be similar to the kernel for the most part.
 106
 107 ## 22:53
 108
 109 Then instead the PVM JVM could use a jit which just uses Java code as its
 110 output instead. So I could effectively work on the JIT at the same time as the
 111 PVM JVM. The JIT would potentially need the facilities to handle Java byte
 112 code translation.
 113
 114 ## 22:56
 115
 116 I would suppose that I will use something similar to GCC's triplets. Except
 117 that it would be quadruplets. `arch-vendor-os-variant`. So some examples:
 118
 119  * jvm-oracle-jvm-javase
 120  * mips-nintendo-n64-64drive
 121  * m68k-palm-palmos-unknown
 122  * powerpc-unknown-linux-gnux
 123
 124 Although alternatively it could be hardware instead of `vendor`.
 125
 126  * jvm-jvm-jvm-javase
 127  * mips-nintendo64-none-64drive
 128  * m68k-generic-palmos-4
 129  * powerpc-generic-linux-gnu
 130
 131 Then there could be a sub-variant of sorts using '_'. This could simplify
 132 things a bit.
 133
 134  * mips_32-nintendo64-none-64drive
 135  * mips_64-nintendo64-none-64drive
 136
 137 ## 23:03
 138
 139 However, the architecture would either be generic or support either one or
 140 both 32-bit or 64-bit (or any other mode). I could also have a unique name for
 141 each individual CPU. Support for specific operating systems, output JITs,
 142 variants, and otherwise should be pluggable. So one could say attempt to
 143 mix and match impossible scenarios such as:
 144
 145  * powerpc-nintendo64-linux-javase
 146
 147 The operating system is an important level along with the architecture. The
 148 architecture could have ABI information but that could be changed by the
 149 operating system. So I suppose when it comes to the ABI selection used by the
 150 JIT, it can have prepackaged supported ABIs. Then the OS just says that it
 151 uses one of the ABIs that are available. This way the architecture and OS
 152 interfaces generally would not touch. The architecture API would just handle
 153 register access, saving states, resuming states, and some other details such
 154 as memory maps potentially. However, some systems may need a slightly different
 155 way to manage memory.
 156
 157 ## 23:11
 158
 159 I would also want variants. Say on Linux there could be a X based interface
 160 while another could use GTK directly. These would have to be split into
 161 multiple projects. However, a basic OS interface could implement the required
 162 details. So essentially they will need to be overridden. So I suppose there
 163 would need to be a dispatching interface of sorts. There would be the base
 164 interace operating systems and variants would use. Then the dispatcher just
 165 chooses one with the most score. Since some systems might get complex, the
 166 variant support should be split across multiple interfaces. This way filesystem
 167 access can be plugged in on top of an existing variant or similar. A variant
 168 could also optionally call the variant with the next lower priority. So this
 169 way if I just need to change the graphical system I can just switch the
 170 class to be used while keeping stuff such as the filesystem.
 171
 172