assets/developer-notes/stephanie-gawroriski/2016/07/04.mkd

   1 # 2016/07/04
   2
   3 ## 11:37
   4
   5 I need to fix the simulator so that instead it is a service based interface
   6 which provides operating system support based on architectures and such
   7 instead of not as concrete sets of data. Get rid of all the providers and just
   8 have a `SimulationProvider` which can create simulations as such.
   9
  10 ## 11:44
  11
  12 Today is just rain.
  13
  14 ## 12:33
  15
  16 The simulation such as architecture variants can be linked to the JIT for
  17 simplicity.
  18
  19 ## 13:16
  20
  21 When it comes to simulating a root filesystem, the basic filesystem layout
  22 could be described in resources associated with JAR resources. This way when
  23 it comes to the binary, no other details have to actually exist. There could
  24 be a special filesystem specifier of sorts which describes the files which
  25 are available on the root. It would not be a simulation of a whole system,
  26 however it should be good enough to allow a basic system to operate
  27 properly. So essentially stuff such as `/bin/sh` for Linux at least would
  28 appear a resource which could use an internal special commands to execute a
  29 command which should be provided by the system (in the event of `system()`
  30 being called). This would also allow specific programs to be ran on the host
  31 without worrying about the host operating system at all. Certain details of
  32 the filesystem, such as block devices and character devices, can be implemented
  33 by classes. The current user directory could be mounted as a certain directory
  34 in the simulated system when applicable. Then this way, I do not have to
  35 worry about forwarding calls to the host system (if in the event the code is
  36 running on Linux). However, this would essentially permit a specific set of
  37 programs to run from any operating system.
  38
  39 ## 13:42
  40
  41 Simulation starting details would best be placed into a single object, this
  42 way I can add more potentially in the future without requiring massive
  43 simulator changes.
  44
  45 ## 16:32
  46
  47 I likely do not need `EmulatedCPU` at all, it could really just fit within
  48 `SimulationThread` which is initialized and emulates a given CPU such as for
  49 PowerPC.
  50
  51 ## 16:56
  52
  53 However, I really need a single emulation core, otherwise I will end up
  54 writing many PowerPC CPU implementations. One thing I could use however is
  55 a generic CPU emulation framework. Not part of the simulator but completely
  56 different. The simualtor itself could use this emulation layer however. I could
  57 also have native emulators available so I can run other operating systems
  58 within them, for example Linux. I could use the emulators in a way where I
  59 could support specific systems in them. I could also just have a much stronger
  60 simulation core also.
  61
  62 ## 17:00
  63
  64 However, the emulation sub-system could be used potentially with the actual
  65 run-time running as a kind of co-process potentially. Although, I could just
  66 have a much simpler simulation system which is not complex at all. I could
  67 sacrifice some things such as multiple processes in a way (although I should
  68 not do that, since some processes may rely on it).
  69
  70 ## 17:35
  71
  72 A problem is that with the CPU manager, I will need to wrap the TLBs and MMUs
  73 for some CPUs. This depends on the number of TLBs which are available to a CPU,
  74 although ones such as x86 use an address in memory to contain page information.
  75 So I suppose what I can do instead is have a high level emulator that can
  76 emulate hardware. I will write an actual emulator which could run operating
  77 systems and uses BIOSes. When it comes to the simulator, they will just be
  78 based on the emulator except that it would provide some high level wrapping.
  79
  80 ## 17:59
  81
  82 Actually being a bit higher than userspace would be handy. So I suppose I
  83 should go for a high level system emulator. This way I can run Linux itself
  84 while I can drop down to lower levels and run Linux programs itself. So I
  85 suppose my initial goal should be running a Linux kernel or perhaps even the
  86 Mac OS X kernel.
  87
  88 ## 21:10
  89
  90 With `unsafe` there is a way where I can get away with not having any
  91 binary stubs and assembly bits.
  92
  93 ## 21:15
  94
  95 Well, when it comes to the binary format, the loading of classes, with linking
  96 when it comes to fields and methods is system dependent. For example when
  97 it comes to ELFs the classes and such can be linked in the binary.
  98 Alternatively I can just have a bootstrap which sets up an executable region
  99 and then jumps into it. Some systems, say a hypothetical POSIX shell target
 100 will not use a binary representation of classes at all. Each class would
 101 essentially just be a field and allocated objects would be files on the
 102 disk for the most part.
 103
 104 ## 22:01
 105
 106 Ok, so having the JIT output to an output stream with some kind of binary
 107 writer does not make sense at all for certain targets. These targets would
 108 be an interpreter which runs on an existing JVM, and perhaps esoteric targets
 109 which do not target binary formats but some other strange format. So basically
 110 the output to the JIT would be similar to before except that when it comes to
 111 output it might output to a binary format, or it might not. I really should
 112 support a kind of JITted interpreter, so that way I can test the JIT and then
 113 the class library with minimal effort. Basically the JIT would output a
 114 `CompatibleExecutable` as a kind of interface. However there may be a case
 115 where the JIT would want to store the result to the disk (say with AOT) while
 116 in other cases it would want it directly in memory ready to be used. So what
 117 I propose when it comes to a JIT that it can output a ready to execute format
 118 or it can use an `OutputStream` to a cached form of the data. These forms
 119 would be very system specific.
 120
 121 ## 22:06
 122
 123 So, I would say it would be best kept to an interface. The interface can then
 124 declare if it wants to output a cached form directly, or also a
 125 `CompatibleExecutable`. Basically the handles for all methods would need to
 126 handle output to be cached or a compatible executable for direct execution.
 127
 128 ## 22:15
 129
 130 This means that the JIT output again becomes non-abstract.
 131
 132 ## 22:18
 133
 134 So actually, I suppose that this instead removes `JITFactory` which then turns
 135 into a `JITOutputFactory` which creates `JITOutput`s which are associated with
 136 a `JIT`. The output factory is then given an architecture and a variant. When
 137 it comes to JIT generation fully handled triplet would be used in the factory.
 138 Then the `JITOutput` created will handle stuff such as writing to binary
 139 formats and such. So the factory creation method would then handle cases where
 140 output is to a cached form or directly executable form. Then when it comes to
 141 actual assembly code generation, there will just be a basic output for
 142 an architecture which uses a compatible interface.
 143
 144 ## 22:23
 145
 146 Then when it comes to the output factory, the variant could be supported or
 147 it might not be. The system specific output handler can see if a given variant
 148 and endianess is supported.
 149
 150 ## 22:27
 151
 152 When it comes to the word size of the CPU, perhaps instead of `powerpc32` it
 153 is instead part of the variant, say `powerpc-32+g4,big`. Then stuff such as
 154 x86 would be `x86-16+286,little`. This way I do not have to have quite a number
 155 of variants which target similar things.
 156
 157 ## 22:40
 158
 159 Probably something to simplify output would be a state that can be changed
 160 accordingly. It can be made immutable when work needs to be performed. So it
 161 would essentially be a configuration of sorts.
 162
 163 ## 22:47
 164
 165 I would suppose when it comes to an interpreter JVM, that instead of creating a
 166 JVM it would just setup a JIT and start executing the JVM as it would in the
 167 instance. Any special calls would then just modify the state. This would
 168 provide a close execution environment. It would also allow me to design the
 169 `JVM` so that it is closer to how real environments would run.
 170