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

   1 # 2016/07/26
   2
   3 ## 07:56
   4
   5 Hopefully today I can get to work on the emulator.
   6
   7 ## 15:29
   8
   9 For the emulator, I thought about having it where I just load the binary and
  10 just start executing bytes in a specific region (perhaps the end). This would
  11 for the most part be how the real system is handled and such. So then this
  12 way I can have binary initialization be written in Java and be generic as
  13 possible. Compiler magic would handle most of the things.
  14
  15 ## 16:35
  16
  17 I really just need components and that is it.
  18
  19 ## 16:52
  20
  21 To support recording and replays, components have to be added and initialized
  22 via factories. However the classes could be used. So the system would have an
  23 `addComponent` which takes a `Class`, `String` (id of component), and
  24 `String...`/`Object...` for the component properties.
  25
  26 ## 18:49
  27
  28 So component creation can be stored in replays. Currently the class type is
  29 stored, so they cannot be changed at all.
  30
  31 ## 19:18
  32
  33 The interpreter runs at 8MHz internally (at least the one created by the
  34 interpreter target builder). 58122500000ps (0.0581225s) was done in about a
  35 minute of just mass printing text.
  36
  37 ## 19:22
  38
  39 Currently my emulator is cycle accurate and extremely slow. It takes 13 seconds
  40 for a 8MHz cycle to complete.
  41
  42         DEBUG -- 1s at 2888363125743347
  43         DEBUG -- 1s at 2888376866173501 (13740430154 or )
  44         DEBUG -- 1s at 2888389859357080
  45
  46 This means that is is really slow, too slow for the emulator to truly be
  47 viable for testing. Although cycle accurate is nice, it is far too
  48 undesirable.
  49
  50 ## 19:25
  51
  52 So what I really need is a kind of deterministic emulator that does not
  53 run extremely slow. So I suppose what I need instead of running a single
  54 cycle for each method, I need a run to amount to occur instead or similar.
  55
  56 ## 19:27
  57
  58 Also, each call essentially is done in a single method, every cycle has its
  59 own method call so there is much overhead. So bulk execution is definitely
  60 needed. There has to be a central loop somewhere which calls all the
  61 associated methods as required and does not cause a method to be called for
  62 each cycle. I suppose what I can do is instead change the emulator code to
  63 not use picotime and instead just have a generic run time amount. Real time
  64 on the system can be virtualized instead. Code to be ran by the CPU could be
  65 read into a buffer and bytes could be interpreted in a giant loop until the
  66 PC leaves the block or a given number of instructions were executed. Then
  67 something I can do is just implement JIT compiling for MIPS instead of the
  68 interpreter. So there would still be an interpreter, but it would just run
  69 MIPS code in my own faux `squirreljme.interpreter` operating system. This would
  70 be a bit more realistic than writing my own instruction format.
  71
  72 ## 19:45
  73
  74 So I suppose this means that the `jit-interpreter` becomes `jit-mips` for the
  75 most part. Perhaps not. I would need to initialize a code generator.
  76
  77 ## 19:49
  78
  79 Having a `jit-mips` would be difficult if it is not OS dependent. I would need
  80 a way to adjust the generated machine code because some platforms may change
  81 how some registers are used or have a different syscall mechanism. So the JITs
  82 will remain the same as targets. So really the interpreter JIT code will be
  83 the same, except that once I get to actual byte code recompilation it will just
  84 generate MIPS code instead.
  85
  86 ## 19:59
  87
  88 So I definitely need a simplification of the emulator, so despite moving to
  89 MIPS I really do not need to do anything much except change the emulator code.
  90 Then at least I would have a single target. So if the interpreter works out
  91 and gets code implemented, I could target Linux MIPS next.
  92
  93 ## 20:05
  94
  95 Thinking about it, although having an emulator which can support TAS would be
  96 nice, it would complicate things a bit. It would also potentially cause some
  97 slow down. So I would suppose that I should drop the very complex emulator
  98 which I plan to have and just go with something far simpler. Setup a basic
  99 machine, load a binary into memory, and just start executing it. Do not worry
 100 about being cycle accurate, just make sure the code runs.
 101
 102 ## 20:17
 103
 104 So I suppose what I need in this case is a traditional JIT that outputs blobs
 105 to be used on standard modern systems with code and memory in a single address
 106 space, which means pretty much every CPU from classic 8-bits to modern 64-bits.
 107 Then I only need to write the JIT once. When the need come to have slightly
 108 different code generators (for architectures) they can just be created over the
 109 base class. So basically a traditional output system. The blobs would
 110 be the same for every architecture. The byte ordering can be determined by
 111 using the triplet easily. So this means that the initial MIPS could instead of
 112 being ELF will just be a proprietary format that is directly the blob format.
 113 Then this way, I really only need to write that code once since all of the
 114 architectures will end up creating the same format anyway. This simplifies
 115 things greatly.
 116
 117 ## 20:21
 118
 119 Then the interpreter target could just support any CPU and not just MIPS. Then
 120 the interpreter will just have some special memory areas or system calls that
 121 do specific things.
 122
 123 ## 21:54
 124
 125 I would suppose for some increased processing speed that strings could be sort
 126 of written inline or at least after the last output has been placed.
 127