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

   1 # 2016/06/15
   2
   3 ## 07:48
   4
   5 The configuration would best be immutable for the most part. This way it could
   6 more easily be used when threads and such need to be created.
   7
   8 ## 07:50
   9
  10 However, perhaps just an immutable class that can be initialized.
  11
  12 ## 07:55
  13
  14 For a mutable variant I can just use a kind of builder.
  15
  16 ## 08:22
  17
  18 I need better names for the CPUs in the builder. I will go with the planned
  19 variants.
  20
  21 ## 08:39
  22
  23 So when it comes to building, I need a JIT that could cache and provide native
  24 executable code fragments for classes and such.
  25
  26 ## 08:43
  27
  28 I believe the simulator with multiple simulations, groups, and otherwise would
  29 be a bit complex. I will just have a single simulation process that runs and
  30 executes until it completes.
  31
  32 ## 08:45
  33
  34 So is the JIT on a per class basis or a per method basis? Classes are together
  35 in a group, so it would likely be better optimized to compile classes all at
  36 the same time.
  37
  38 ## 09:55
  39
  40 A configuration system for configuring builds would be the best rather than
  41 just a CPU and OS target.
  42
  43 ## 10:04
  44
  45 I would suppose that I have base OS support and then a front end that could
  46 work on the OS to provide an interface for the user. The front end could vary
  47 for a system and provide alternative control and featuresets.
  48
  49 ## 17:56
  50
  51 The manifest code needs a new exception.
  52
  53 ## 18:05
  54
  55 The package code should be placed in another location for the most part. Then
  56 thinking about it, I can adjust the build system (`Build.java`) so that it
  57 uses the package code rather than duplicating it and such.
  58
  59 ## 20:27
  60
  61 Thinking about it, I suppose operating system support should be a part of the
  62 JIT. However generally not. The JIT will need to translate special method
  63 calls into some other form. Calling the special magical methods could just be
  64 transformed to a call to another class. However the ABI for the OS must be
  65 matched, otherwise using native debuggers would be much more difficult. So in
  66 generally, I suppose a class which is needed would be a system description
  67 class. However it needs to be able to support multiple architectures and such
  68 also. However, when it comes to the classes it could be automatic somewhat.
  69
  70 ## 20:32
  71
  72 One thing though is that I will need to support variants which could overload
  73 pre-existing definitions. Basically these would be front ends and backends.
  74 Perhaps multiple backends could be supported at once, but that would be
  75 complex. Thinking about new code layout, I may want to remove the following
  76 projects:
  77
  78  * `event-manager`: Could be replaced with something better and be implemented
  79    when actual UI comes into play.
  80  * `gc`, `gc-standard`: Rework these interfaces.
  81  * `interpreter*`: Remove these and do not support interpretation at all,
  82    interpretation is slow. However for a simulated build environment I could
  83    instead use a JIT of perhaps say MIPS or MMIX and then run it in a simulator
  84    to act as an interpreter. The hypothetical IDE I have had an idea of could
  85    just compile to a specific machine and then run the produced binary in the
  86    simulated environment. This could also be used to check for bugs also.
  87  * `kernel-*`: The kernel is somewhat nice with processes and threads, although
  88    there are some complex details. What is generally just needed when it comes
  89    to the virtual machine is the launcher interface, but a kind of IPC between
  90    running sub-VMs. Instead of system specific kernels, the support for a given
  91    system can instead be provided by the `os-*` packages. Threads and
  92    processes would just use differing object spaces within the same process
  93    memory space.
  94  * `mmu-*`: The `MemoryAccessor` interface is nice to have. One thing to
  95    consider is that I could move it into `__squirreljme` and make it available
  96    and dynamically translated by the JIT. If a constant pointer is read it can
  97    potentially translate it directly. A requirement of `__squirreljme` would
  98    be that all method calls would be rewritten into other locations. So when
  99    it comes to the JIT and OS variants, there could be code that just overrides
 100    which method gets executed.
 101  * `runtime-objects`: This would be consolidated to a new object manager and GC
 102    in one.
 103
 104 ## 20:42
 105
 106 So I suppose when it comes to the JIT, I just do a straight translation and in
 107 general just replace magical calls as required. I can have a common register
 108 availability class that the JIT uses and such.
 109
 110 ## 20:45
 111
 112 So the JIT needs a `JITCPUProvider` which provides support for generating code
 113 for a given CPU.
 114
 115 ## 20:47
 116
 117 As for the internal `__squirreljme` magic, the kernel can translate magical
 118 calls while the JIT which would run on the target would not translate them (so
 119 that they throw exceptions). All programs would source their classes from the
 120 built-in class path anyway.
 121
 122 ## 20:55
 123
 124 I suppose there would be multiple support layers the build system would use to
 125 determine how to target a given system. `jit-powerpc` would be the basic
 126 PowerPC support while `jit-powerpc-linux` would be the variant that works on
 127 Linux. Then the `os-*` packages would just contain operating system support
 128 code such as file system accesses and system calls. There would also need to
 129 be architecture specific operating system information. So I would also need a
 130 `os-linux-powerpc`. So `jit-powerpc-linux` would help indicate code that is
 131 friendly to the Linux OS while `os-linux-powerpc` would contain the
 132 architecture specific Linux support code. I suppose when it comes to the
 133 run-time there is a base abstract class which is primitive OS handling and
 134 interfaces, abstract where appropriate. Although this would likely best be in
 135 `__squirreljme`. It could work at this position. I can use faked global init
 136 of sorts.
 137
 138 ## 20:59
 139
 140 Basically there will be an abstract class which has a static instance which
 141 allows the standard run-time to communicate with the OS as required. Then the
 142 target system's initialization will magically set the value of a static field
 143 so that the interface is initialized and useable. That way, any calls made into
 144 the singleton will instead go to the operating system specific support library.
 145
 146 ## 21:04
 147
 148 The `__squirreljme` package is literally just `unsafe` stuff, so instead of the
 149 special package I could just place it in
 150 `net.multiphasicapps.squirreljme.unsafe`.
 151