assets/developer-notes/stephanie-gawroriski/2017/01/31.mkd

   1 # 2017/01/31
   2
   3 ## 09:58
   4
   5 Today, hopefully work on the MIPS JIT will be done.
   6
   7 ## 12:00
   8
   9 So I was thinking of a configuration system again. Each system will need stuff
  10 such as the endianess, the CPU flags, or other such things.
  11
  12 ## 12:03
  13
  14 Then those settings will have to be re-initialized somehow via a kind of
  15 serialization of sorts. However, the problem with some things is that there is
  16 no reflection. So this means I cannot just see which values exist in an
  17 enumeration. I would need objects at run-time to have these configurations. So
  18 things would probably be best static. If a JIT needs initialization by the OS
  19 specific part, it can have the means to choose which JIT things should be
  20 initialized with.
  21
  22 ## 12:10
  23
  24 However, I will need some kind of singular class which can be given options
  25 and such.
  26
  27 ## 12:14
  28
  29 Along with a builder of sorts and deserializer from say a map. So a builder
  30 would make things a bit easier, because I would not want a constructor
  31 with a few thousand arguments. I would also not want to rewrite builders all
  32 the time also. I would suppose that for simplicity, I will violate the final
  33 constraints and such and have the potential for things to be modified. Because
  34 many CPUs are different and having fixed constraints in some cases would be
  35 messy. So for example the base would have stuff on the byte order for example,
  36 it would have a non-final byte order method. If a byte order was set by the
  37 initialization (say the `endian` option), then it will return that one.
  38 Otherwise it will throw an `IllegalArgumentException` saying that none was
  39 specified (or a similar exception). But, seeing that it is not final, for
  40 some CPUs such as the x86, the method can be overridden to only return a
  41 single value so it does not actually fail.