assets/developer-notes/stephanie-gawroriski/2015/03/19.mkd

   1 # 2015/03/19
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 09:44
  10
  11 Instead of having OpAllocObject and the method invocation translators (the
  12 macro creators), I can just have a generic method obtaining and creating the
  13 macro information for those operations. This way, the way calls are done is
  14 less duplicated among all of the architectures and is more cleanly placed.
  15 Doing as such should reduce bloat and copied code among all implemented
  16 architectures.
  17
  18 ## 10:31
  19
  20 Swizzle meta must become an actual sub, since it could be embedded.
  21
  22 ## 10:38
  23
  24 Swizzle would also probably be best manually specified rather than having it
  25 auto as it makes macro usage easier.
  26
  27 ## 10:56
  28
  29 An added type enumeration would be extra handy for step handling as I can use
  30 a switch rather than a complex set of if on class instance types.
  31
  32 ## 11:11
  33
  34 So what I need now is to determine how the actual calls are going to be done.
  35 I will need some way to access the table for an object so that a method may be
  36 invoked. Perhaps I can have two areas. The static class area which contains
  37 the method data and such (can be in ROM). Then there will be the dynamic
  38 linkage area which points to the base of that data and then consists of linked
  39 table entries for all the needed addresses. The classes which objects will
  40 will the point to that data. The table will need classes and interfaces
  41 however, and it needs to be stacked in a way where superclasses can have their
  42 methods called as needed.
  43