assets/developer-notes/stephanie-gawroriski/2017/08/11.mkd

   1 # 2017/08/11
   2
   3 ## 09:14
   4
   5 One thing is that keys are forced to lowercase, which means the rewrites would
   6 need to be lowercased also. Although having the camel casing is nice. I wonder
   7 if there is an elegant solution to solve this. Well actually there is.
   8 Whenever a class matching the unsafe internal form is used, it can be forcibly
   9 lowercased. Although that would be a bit hacky in many situations. Also on
  10 another note...
  11
  12 ## 09:18
  13
  14 I forgot what that note was.
  15
  16 ## 09:32
  17
  18 Ok so the `TargetBuilder` class definitely needs a refactor and templates need
  19 to be a bit stronger. I can turn it into a better system since right now it is
  20 a bit ugly in a way.
  21
  22 ## 09:35
  23
  24 When an architecture is specified I will need to include some common stuff
  25 for architectures. I could actually keep manifests. But one thing which would
  26 be nice is the ABI, having it in the configuration means that I do not need to
  27 hardcode ABIs and they can be crafted at will. I would however need an ABI
  28 description language or builder of sorts just to generate them unless I type
  29 all of them in manually. It could be useful though and would remove that code
  30 from the JIT itself. Then if the ABI changes slightly like maybe a register
  31 should be reserved and not used, it could be removed.
  32
  33 ## 10:12
  34
  35 So how do I handle better templates? Maybe I should worry about the better
  36 template handling when I have more JIT code even though I know I will run into
  37 problems. I will keep it simple for now and then refactor it when I know what
  38 to expect from the JIT and build system.
  39
  40 ## 10:15
  41
  42 One thing the naive generator will do is when there is a rewritten to
  43 assembly method call there would be copies of the input made since they would
  44 be on the stack and such, but not going to worry about that for the naive
  45 generator since it is as simple as possible.
  46
  47 ## 10:16
  48
  49 Thinking about how SquirrelJME operates, I wonder if I even need a kernel.
  50 Most of the execution would be in threads and be rather linear. Only some
  51 systems will need a schedular for example, but ones with scheduling already
  52 would not need a kernel as they can just act on threads. So definitely the
  53 kernel is to go away now.
  54
  55 ## 10:17
  56
  57 I do need to know the threads that exist however so they can be managed. But
  58 in reality there just needs to be special calls that handle special things. So
  59 I need a kernel but something not as complex as I had before. I can have most
  60 of the processes be rather adhoc. So it really becomes just a manager. The
  61 manager could have different sub-types such as being cooperative and such.
  62
  63 ## 10:21
  64
  65 In reality though, there is the launcher. Personally the launcher itself could
  66 be the kernel which does all of the special things that are expected of the
  67 launcher. This means that the LCDUI code will probably have to change again to
  68 handle the launcher interface. But there could be an unsafe system class which
  69 directly interfaces with the launcher wherever it is running and calls into it
  70 for the most part. I think that would be a much simpler and lighter design
  71 that would be easier to maintain. Definitely the existing kernel as it is is
  72 too complex. I really just want a launcher with a main interface that can be
  73 used. I will need to figure out how the LCDUI code is managed with multiple
  74 applications and threads accessing it at the same time, but not having it
  75 where it is really slow.
  76
  77 ## 10:28
  78
  79 Any calls made from the launcher will just be determined extra special and
  80 would be considered the "kernel" call.
  81
  82 ## 10:32
  83
  84 I suppose one thing that would be made simpler if process groups and such were
  85 associated with threads instead. Basically everything within SquirrelJME is
  86 ran as a thread which interacts with the main whatever. There is no separation
  87 for sub-processes at all. CLDC cannot list the threads that are being used
  88 they can only get the current thread. So I could actually use this to my
  89 advantage, it does simplify things although there would need to be thread
  90 lookups to determine which process a thread is in.
  91
  92 ## 10:35
  93
  94 This greatly simplfies the design as handling of processes is no longer
  95 needed. The only thing is that processes cannot terminate themselves. All of
  96 their loops will have to fall out. So I need to check this within MIDP3 to
  97 what it expects.
  98
  99 ## 10:37
 100
 101 There is the destroy state. Hypothetically if a MIDlet is running and it
 102 leaves threads behind then it will just continue to happily execute. But
 103 actually the one main issue with multiple threads is a big one, and that is
 104 pretty much static variables and such. In the thread sense all statics are
 105 shared with each other, which is something which should not occur at all.
 106 Two processes running at one would completely destroy each other if they
 107 shared statics in any way.
 108
 109 ## 10:42
 110
 111 So this state of globals complicates things. But this thread idea is
 112 definitely one to do things. At least for global statics, instead there can
 113 just be a pointer to the current thread's globals.
 114
 115 ## 10:43
 116
 117 So I have said this before, probably the best first target instead of being
 118 native where it would be hard to debug things, I think the best first target
 119 would be an emulated MIPS environment. MIPS is simple to write and simple
 120 to execute. At least with that I can get a feel of how things will work
 121 natively before I actually write native things.
 122
 123 ## 10:45
 124
 125 But I actually do not have to support MIPS. There is a virtual architecture
 126 I plan to support which has a large number of registers: MMIX.
 127
 128 ## 11:06
 129
 130 Ok so the first thing to do is target MMIX for an emulator of sorts. For the
 131 most simplistic purposes there will be a translator that is even more naive
 132 and is only made for the simulator environment, with its large array of
 133 registers. I would say SquirrelJME itself would always run in user mode with
 134 a virtual operating system on top whichn interacts with the host system.
 135
 136 ## 11:08
 137
 138 One optimization I can perform though are the translator projects, they can
 139 be forked off so tha they are not in the main JIT. This would produce lighter
 140 JIT implementations since they only need what they use.
 141
 142 ## 13:57
 143
 144 I can actually have a debug dumping translator.