assets/developer-notes/stephanie-gawroriski/2017/07/07.mkd

   1 # 2017/07/07
   2
   3 ## 01:12
   4
   5 Ok so, basically when it comes to fields and methods I need to figure out and
   6 build structures for objects to consist of. Basically I am going to define a
   7 bunch of structures that each class uses to refer to fields. Then for static
   8 fields I will need pretty much a static area that is stuck into a single
   9 section since that is all that is really needed.
  10
  11 ## 01:15
  12
  13 One good thing about this static compiler and how I am writing it is that I do
  14 not need to handle dynamic sizing and such at least until the linkage stage is
  15 performed.
  16
  17 ## 01:20
  18
  19 I think my `Dynamic` and `Dynamics` is a bad idea. Basically the dynamics are
  20 part of the generated code in sections rather than being a dynamic as a whole.
  21 I mean combining and merging dynamics will result in probably less memory
  22 usage but with the compiler design that is not really much of an issue. So
  23 `Dynamics` go away and are just basic parts of sections that do lookups
  24 depending on the situation and have dynamic resolution things as needed when
  25 section bytes really need to be read.
  26
  27 ## 01:24
  28
  29 So dynamics based on my comment text would be imports from a set of exports.
  30 But those might not really be known. The imports would be the entire thing for
  31 the most part. Well basically the dynamics are for caching. Say that a class
  32 object is at a given address somewhere special. And this will vary for PIC and
  33 not PIC (fixed addresses). So really based on the config the generated
  34 instruction in the section will totally differ based on the situation.
  35
  36 ## 01:28
  37
  38 However the non-dynamics would be like accesses, but basically they are just
  39 conditions. Essentially that say a given class is extendable or similar. I can
  40 for the most part check whether things are sane all at once at the end. So
  41 this would reduce the checks that cannot be performed at class decoding. This
  42 works because I can just do the compilation stuff at first. In most cases the
  43 conditions will all pass anyway. This also allows me to defer and simplify the
  44 compiler so I do not need to handle complex verification issues until the
  45 later stage.
  46
  47 ## 01:33
  48
  49 So this new set of classes will be conditions. Basically the conditions will
  50 be like: does `Foo` implement `Bar` or is `Foo` castable to `Bar`? Essentially
  51 doing a bunch of this verification at the end allows me to not worry about
  52 preloading classes wasting time and memory when in most cases all classes will
  53 pass anyway.
  54
  55 ## 02:29
  56
  57 Conditions will get their own package because there will be quite a few dozen
  58 of conditions declared.
  59
  60 ## 03:15
  61
  62 I think one thing I will do for methods is have an indirect pointer based on
  63 the class type of an object. Basically my previous plan was to have the method
  64 pointers in the objects but that is not needed at all and complications things
  65 a bit. So basically there will be a method table for each class unit which is
  66 then read off as a pointer. So it is like `((uintptr_t)classp + methodoffset)`
  67 where that is a function pointer which is executed. This then allows classes
  68 which override methods to just replace those pointer points and such. I
  69 suppose then special `specialinvoke` would just use the class table on any
  70 object in a way violating some things but still being somewhat compatible. So
  71 this way of doing method pointer lookups is much simpler. Of course then there
  72 are interfaces which is another thing to figure out. However at least here the
  73 methods for objects are handled. Objects will need a hash code field and the
  74 class pointer field. I also then suppose the `Class` instances would be mostly
  75 static for the most part. Well `Class` objects need initialization. I mean
  76 basically I do not need to have the method tables exactly at the end of the
  77 class, they can just be part of static class data which is then pointed to by
  78 the class object for reading things. So this static table would have access
  79 flags, the default constructor (if any), and a table of methods that are in
  80 the class in extendable replacement order.
  81
  82 ## 03:31
  83
  84 Only way for it to work better would be for the method table to be somewhere
  85 in the `Class` instance. This at least can handle relocations and such. Static
  86 method calls on the other hand do not require any method table usage because
  87 they are not bound to objects.
  88
  89 ## 14:45
  90
  91 One thing I will need to do is generate array classes and perhaps have it
  92 where you cannot just lookup non-existing array classes if they are never
  93 statically referenced. So if there is no usage of '[[[[I' then
  94 `Class.forName()` will not find any class. This simplifies things, makes it
  95 still work and does not need it where I need to worry about generating new
  96 classes at run-time. Also another idea I have is have a non-zero NULL for
  97 objects. Although this would differ from integer values it simplifies
  98 handling of objects and determining if they are NULL or not. Basically it
  99 can done where any method calls performed on the object with relation to
 100 the class regardless of which class it is will result in a NPE being thrown
 101 by any method calls without modifying anything about the stack and such. So
 102 basically it just disregards arguments and just throws a NPE. This however
 103 means that _monitorenter_ and _monitorexit_ will need to be actual methods
 104 but I intended this anyway. Naturally the null class will never compare or
 105 is an instance of another class anyway. Also the initial methods for all
 106 classes inlcuding the null class can include special things such as checking
 107 for instances. The only issue would be fields, there would need to be checks
 108 if the object is `null` before fields are attempted to be accessed. Also the
 109 null class/object pointer would have to be known or fixed and allowed to
 110 make things work well with them. However the alternative is to instead for
 111 method calls have the NPE check on `this` on entry of instance methods and
 112 just treat all methods as being static for the most part. The `this` is
 113 always passed anyway. Of course objects that are null cannot get their classes
 114 dereferenced, so no null checks are needed except before method calls. Also
 115 for the NULL class I would need a complete set of methods for the maximum
 116 possible depth. So having a NULL class would complicate things and require
 117 them to be set anyway. So bad idea!
 118
 119 ## 15:10
 120
 121 So according to Java SE runtime tests, using `Class.newInstance()` in the
 122 given cases:
 123
 124  * private: FAIL
 125  * package-private: PASS
 126  * protected: PASS
 127  * public: PASS
 128
 129 Now if I put it in another package?
 130
 131  * private: FAIL
 132  * package-private: FAIL
 133  * protected: FAIL
 134  * public: PASS
 135
 136 So when it comes to `newInstance` it seems that `protected` is the same as
 137 package private.
 138
 139 ## 15:25
 140
 141 So that is an interesting observation.
 142
 143 ## 15:40
 144
 145 But `new` works when it is in another package. And `Class.newInstance()` acts
 146 like `new` at the language level and not the virtual machine level.
 147
 148 ## 15:46
 149
 150 Well today I learned, in the same package that protected classes can be
 151 constructed but outside of the package they need to be extended. This is at
 152 least according to the compiler. But at the VM level, you can `new` and invoke
 153 protected constructors like they were public. And the classes do not even need
 154 to follow the same hierarchy. So this means with specially crafted classes
 155 that `protected` on a constructor is not enough to protect a class from being
 156 initialized.
 157
 158 ## 15:58
 159
 160 So since you can `invokespecial` `protected` constructors. This is probably
 161 not something that may have been intended?
 162
 163 ## 19:32
 164
 165 Actually I have an idea about what to do with the emulator. I can have a
 166 simulated executable environment which is just the flat binary placed
 167 somewhere and run in a special enviroment. It would just be MIPS for the most
 168 part but just as a flat binary.
 169
 170 ## 19:37
 171
 172 I now own Amiga Forever and C64 Forever, so I am going to use these eventually
 173 to port SquirrelJME to these two systems. It would be an interesting
 174 experiment.
 175
 176 ## 20:06
 177
 178 Ok so for methods, there will basically be `UnitMethod` which will be
 179 contained in `Unit`s. There would also need to be checking for overriding too.
 180
 181 ## 21:23
 182
 183 I could split identifier into three, one for classes, fields, and methods.
 184 Then make them unique. The only variant would be for methods.