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

   1 # 2016/09/01
   2
   3 ## 07:26
   4
   5 A new month is now.
   6
   7 ## 07:54
   8
   9 So there have been 554 commits this month. Let us see what I have done. I did
  10 some refactoring of DynamicByteBuffer but that class went away. Removed Zip64
  11 support and plans. But the resulting and eventual use of `ByteDeque` is rather
  12 nice for the most part. I made the inflation code much faster, something that
  13 is a bit more sane. I started a bunch of JIT work also. Basically, I wrote a
  14 rather nasty ELF output, but then rewrote that to be much nicer and more
  15 reuseable for other systems. Did a bunch of JIT refactoring and work so that
  16 the JIT is rather nice also. I just now need to implement register allocation
  17 for generic targets. Spent a number of days trying to figure out why my ELF
  18 output was not working, but I eventually figured it out and decided to just
  19 rewrite all of that code. I made the base JIT much more sane as previously
  20 mentioned some more. Setup a basic generic binary output which is mostly
  21 16-bit currently to save as much space as possible. I added handling of POSIX
  22 paths, since I will need that for native I/O and emulation of binaries for
  23 a given system.
  24
  25 ## 08:05
  26
  27 Thinking about it, my emulator for Linux MIPS can be very simple. It can just
  28 load in the ELF binary and then start executing it as if it were an executable.
  29 Then I could just for the most part treat it as a chunk of memory for the
  30 most part. I fixed up Lex a bunch of times and made some improvements which
  31 are quite a bit noticable, they do look better. Near the end of the month I
  32 actually got some code running on the reference implementation, despite it
  33 just throwing TODO. I will need to have more a test system in place where I can
  34 load all the JARs that I can or at least merge them into a single JAR for
  35 quick testing. Basically what I will need to do is, since I believe the
  36 liblets are not being considered by it (it should have complained about them
  37 missing, but it did not), would be to have a special output that can repackage
  38 the binaries for running on said environment. Then if I can run the tests on
  39 it, I would then be able to see what works and how things are different
  40 compared to OpenJDK and that environment. I would completely manage it in my
  41 own code, in Java, but have a helper script and such. Since it requires a
  42 Raspberry Pi, I can setup one that sits around. I placed in the skeletons for
  43 MEEP LUI, Key, and MIDlet. However, one thing I have to do is rewrite the
  44 build system and have a kind of bootstrap. Then my build system would for the
  45 most part be written for SquirrelJME and once I get a Java compiler, it would
  46 be self hosting for the most part. The only issue would be building and then
  47 potentially executing the JARs. However, if when I get enough of a working JIT
  48 that can recompile code, I can always implement an interpreter on top of that
  49 which could run the native code. Likely the best choice would be to have it
  50 generate MIPS code and then setup an emulator that uses the host filesystem
  51 and such. So although the programs being ran are purely emulated it would seem
  52 as if they were not (at least filesystem wise anyway).
  53
  54 ## 08:56
  55
  56 Ok, so while I was away I thought about renaming the package manager to just
  57 projects and then renaming the package also. I also thought about that
  58 exportation I was talking about, where I would merge multiple JARs into one
  59 and create a JAD of them. One thing I could do is have a kind of system where
  60 I can export the JAR and then depend on other parts. Essentially since the VM
  61 is similar to Java 7 but without `invokedynamic`, what I can do is basically
  62 go through the class files and rewrite part of their constant pools during
  63 method processing and such. Essentially I can JIT the byte code. Although in
  64 reality, what I could do is a kind of JIT which similar to the generic JIT
  65 just targets existing JVMs. I thought of this before, although the best choice
  66 would likely to be just to expand and add another JIT which targets the JVM.
  67 Then I can have a cross-compiled environment to J2ME for example. The only
  68 issue would be that the JVM code would have no JIT, so it would essentially be
  69 limited to running built-in packages. Then I would need to modify statics so
  70 that they are purely instances only. I would also need to implement writing
  71 of the old style `StackMap` attribute also. The end result though would be an
  72 environment I can run on J2ME devices (such as my phone and PDA) before I
  73 actually support said systems. One thing that would likely be recommended
  74 would be to have it where each version can be separated. Since I only have a
  75 limited bandwidth on my phone, I would want it where I can run newer and
  76 older environments. But first, I will rename the package manager code.
  77
  78 ## 14:29
  79
  80 Actually the register allocator only needs to know about the stack and the
  81 general purpose registers to choose. It does not need to know about the
  82 constant pool or the method pool because that is handled by the JIT itself
  83 when it needs to access things.
  84
  85 ## 14:53
  86
  87 Well, I need a more complex register setup system. I really should match the
  88 ABI of the host, this way I do not have to do mass saving and restoring when
  89 I need to make a system call or calling a library support method. Also matching
  90 the ABI would make debugging it easier with gdb.
  91
  92 ## 15:07
  93
  94 Ok, so on real systems, each register has a purpose. Also for a given ABI there
  95 are arguments, temporaries, alignments, and other such things. Currently my
  96 code would be heading twords initializing this information all the time which
  97 would be quite expensive and rather wasteful. I need to have a builder of
  98 register setups and such and then just re-use that. This would mean a single
  99 object shared across all instances of the JIT.
 100
 101 ## 15:10
 102
 103 I should also look at differing ABIs such as for PowerPC, SPARC, ARM, and x86.
 104 Then I can get a better idea of what the register information has to store
 105 and such.
 106
 107 ## 15:13
 108
 109 Then after that, instead of having allocator factories, the generic JIT is
 110 just associated with the GenericABI. Then the register allocator is completely
 111 internal for the most part.
 112
 113 ## 19:23
 114
 115 One thing I can do instead of using `CPVariableType` is used another but
 116 explicitely for a register type. I can specify a fixed size or the word size
 117 of the CPU, then this way I do not need two separate sets of registers for
 118 32-bit and 64-bit.
 119