assets/developer-notes/stephanie-gawroriski/2016/09/03.mkd

   1 # 2016/09/03
   2
   3 ## 07:01
   4
   5 So now the emulator.
   6
   7 ## 07:36
   8
   9 So what I need is a filesystem for the most part, or at least a source of
  10 files.
  11
  12 ## 07:38
  13
  14 So that would be basing off `NativeFileSystem` at least what the emulator
  15 will use. So I need perhaps emulator specific volumes. Although one thing I
  16 can do to reuse code is have an abstract filesystem that is completely
  17 virtual for the most part. File access and roots can be handled by classes
  18 using it. I can make this code not use anything that has a part of the
  19 emulator so that it can be reused by SquirrelJME outside of it. So this
  20 would be in effect a completely virtual filesystem.
  21
  22 ## 07:47
  23
  24 The emulator could have a virtual ZIP file source, probably as another file.
  25 Essentially it would be one that uses the ZIP code.
  26
  27 ## 07:59
  28
  29 One thing I must determine though is how I want to setup the VFS.
  30
  31 ## 09:00
  32
  33 It may actually be more efficient to calculate the jump targets of the byte
  34 code and then pass that information to the method writer so it only has to
  35 keep a specific amount of state for jump targets.
  36
  37 ## 10:04
  38
  39 So register allocation is simple, I just need a simple way to store the states.
  40 One thing though is that locals and stack item sizes are known in methods and
  41 I only need to store state for all of those locals. So I will need to pass the
  42 number of locals and stack items as Java sees it to the JIT.
  43
  44 ## 10:07
  45
  46 And writing this, I got deja vu, in fact double deja vu.
  47
  48 ## 10:16
  49
  50 I am actually going to need a complex multi-queue. Basically it is like a
  51 `Deque` except that it can have multiple queues in it that obtain stuff from
  52 the same source. Basically the class would be a `MultiSetDeque` in that an
  53 object could only be stored in a queue at once, but there could be multiple
  54 internal queues. This can be done with wrapping `Deque` and using a `Set`.
  55 When something is polled from the queue, if it is not in the `Set` then it
  56 is removed and forgotten about. I will need this for the register allocator
  57 because I need separated int and float registers to grab from, but for example
  58 in MMIX float and int are stored in the same registers. As such I would need to
  59 remove and/or split registers between dedicated integer ones and float ones,
  60 which would very much waste them.
  61
  62 ## 10:37
  63
  64 I do need it to be four of them, for saved and unsaved ones for both int and
  65 float types.
  66
  67 ## 12:44
  68
  69 I should sign my commits.
  70
  71 ## 17:12
  72
  73 One thing to consider is what happens when clear is called on one of the
  74 sub-deques.
  75
  76 ## 17:41
  77
  78 One thing I can do for simplicity although it could be complicated is that if
  79 software float is detected it can automatically change the floating point
  80 types accordingly before passing it to the actual JIT implementation. So in
  81 short, the JIT if it sees software float being used it will handle that.
  82
  83 ## 17:55
  84
  85 I need a kind of storage for values. Essentially for local and stack variables.
  86
  87 ## 18:36
  88
  89 Testing GPG a bit more.
  90
  91 ## 18:56
  92
  93 And another test.
  94
  95 ## 19:02
  96
  97 I could always in a way initialize an initial state with `GenericAlloctorState`
  98 and use that for storing things. However with that I will need to know which
  99 registers are available in the queue and which ones are bound in places.
 100
 101 ## 19:31
 102
 103 When it comes to objects, I do not actually have to skip anything because on
 104 64-bit systems a single register will store a pointer. I just need to consider
 105 the stack when it comes to objects.
 106