assets/developer-notes/stephanie-gawroriski/2016/03/26.mkd

   1 # 2016/03/26
   2
   3 ## 02:06
   4
   5 For stack entries, I need to actually hide when the stack grows a bit too
   6 small, since currently they are treated like locals.
   7
   8 ## 16:12
   9
  10 Was mowing about 2 acres of grass. Anyway, I have an idea for semi-whole
  11 program optimization when it comes to fields. When I load a class I need to
  12 have it so that partially loaded classes can be read. Then if global
  13 field optimization is enabled, I look in the partially loaded set of classes
  14 to see if one matches the field the class is in. If it is found, then the
  15 flags and potential constant value of the class determine if the value is
  16 treated as constant or not. By default if it is not enabled then fields in
  17 other classes would be treated as always volatile, while fields in the current
  18 class are treated with their respective flags and values. I have to watch when
  19 loading classes though, that I do not fail if the dependent class is malformed.
  20 I would have to catch the `JVMClassFormat` error and then just default to the
  21 `volatile` state. Also, to prevent failing classes from loading again I can
  22 put in a list of failed classes which are not in the classpath at all. That
  23 way they are never retried over and over again.
  24
  25 ## 19:02
  26
  27 One thing though is that there has to be checking whether the operations
  28 flow correctly when they go from one set to another. I could actually be
  29 smart about it and put the code in the program state atoms and such. Doing it
  30 that way would also mean I can easily handle the metadata also without having
  31 the metadata handling code everywhere. So I would essentially perform a virtual
  32 not yet done push to the stack of the current atom to affect the next atom.
  33 If the next atom has state set for it and has variables then it is made sure
  34 that the given state would still be valid. So essentially, do a virtual pop of
  35 of the stack (does not actually change the state), then perform the operation
  36 of it where the result is stored in the target atom. If the target atom has
  37 state then it must match (except for the operator links). This I suppose would
  38 be the cleanest way to handle the operator links, since having that code in
  39 all of the byte code handlers would be very messy and error prone.
  40
  41 ## 19:10
  42
  43 Actually looking at my code, the previous slot for the previous operation
  44 is incorrect.
  45
  46 ## 21:32
  47
  48 Thinking about it, I wonder what would be the cleanest and efficient way to do
  49 what I wrote previously about performing operations on the next of state.
  50 Perhaps I could use internal temporaries of sorts, however those might not be
  51 needed at all because the operator links are just virtual. If for example `dup`
  52 is called which duplicates a stack element, then it just copies the operator
  53 link without requiring temporary variables at all. Thus the code generator
  54 would be smart enough to know that no actual work has to be done for said
  55 operations. The stack contains most of the work however. So I suppose a
  56 method which contains the operation to perform which also pushes the result
  57 to the stack with the correct operator links and such. Then later on when
  58 store needs to be done, the opposite effect. The only operation which really
  59 takes from the locals and stores a value back in without using the stack is
  60 `iinc` (which can also be used as an explicit add). So initially the first
  61 method will be essentially `operatorLocalToStack` which reads a local,
  62 performs an operation, and places the result onto the stack. That seems simple
  63 enough. Then it can check the target atom to make sure that it has the correct
  64 state and such specified (that is, it would result in the same stack if it is
  65 explicitely set).
  66