assets/developer-notes/stephanie-gawroriski/2019/05/26.mkd

   1 # 2019/05/26
   2
   3 ## 08:08
   4
   5 In the Boot RAM I am going to make everything actual chunks so it could be
   6 freed more easily.
   7
   8 ## 08:45
   9
  10 This looks a bit strange, but:
  11
  12  * `Seed 00100004 (mod=R, siz=4): 00000004 -> 00100004`
  13
  14 My initial RAM value seems to be seeded with its own address? Maybe the boot
  15 RAM loader is wrong or the boot RAM writer?
  16
  17 ## 08:47
  18
  19 Okay so the first initializer is that 0x00000004 should not be 4 but it should
  20 be the address of the next block. So perhaps the block links are incorrect?
  21
  22 ## 08:49
  23
  24 So I also have in the initializer writing `0 (8) + 248 => 248`. So 248 should
  25 be written to 0x00000004. So a byte is written then the address. And it is
  26 read back in the correct order.
  27
  28 ## 08:54
  29
  30 Okay so I have confirmed that 248 is written to the first two addresses.
  31
  32 ## 08:59
  33
  34 Actually scrolling by I see `(m=null, a=00000000, v=8)` so somewhere in the
  35 bootstrap there is a bad write that is not writing in the correct offset
  36 position, so it ends up being replaced.
  37
  38 ## 09:01
  39
  40 Definitely saw an error in the static field initializers, it just used the
  41 static RAM offset. The values 4 and 8 being written makes sense because those
  42 are the values for the offset static fields.
  43
  44 ## 09:02
  45
  46 Now the RAM links run longer, so I think it is working.
  47
  48 ## 15:08
  49
  50 So I need like actual method indexes and offsets, along with initializing the
  51 vtable for classes. So do wonder how I will do this... I could either do it
  52 in the initializers at static bootram time (faster) or at VM time. But I think
  53 it will be easier to do it at bootram time.
  54
  55 ## 17:05
  56
  57 Okay, I do not believe I need an actual `vtable` for SPECIAL and VIRTUAL
  58 invokes. Okay so, here is my logic. Any virtual call will always call the
  59 highest virtually replaced method in a class. Now `SPECIAL` works on
  60 constructors and super-classes which are not virtually replaced at all for
  61 the most part. So virtual works on the class type of the instance, while
  62 special operates on the class type that was specified. It uses the same
  63 virtual lookup. It uses the same virtual lookup as normal stuff but it ends
  64 at that class instance. Of course this is not the case because. We just want
  65 to work on the virtual table of the super class. The only difference being
  66 the constructors and such which have slightly different logic. Okay so I got
  67 it, maybe. If the class we are targetting is the same... actually forget
  68 that. If we are calling an instance initialization method we want to call the
  69 exact one. But I am pretty sure I can get away with using the special stuff
  70 using only a single table.
  71
  72 ## 18:38
  73
  74 Not sure how I want to do vtable initialization. It is a bit complicated! As
  75 there are package bounds for package-private and no bounds for private
  76 methods. But this is literally the last thing to do.
  77
  78 ## 20:50
  79
  80 Okay so I need to load the pool for the target method and that has to be done
  81 in the instance code. So the vtable also needs to contain the pointer to the
  82 constant pool of the class. So I guess I will need to multiply by two and then
  83 add one just to get the pool data. That is really the only way I can think of
  84 to get both things at once. However, it could just be in another array and I
  85 think that is the simplest really. Once I know the class to load the vtable
  86 from I can load the constant pool array as well.