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

   1 # 2016/09/07
   2
   3 ## 09:43
   4
   5 Actually the other way around would be better. That is having the Set use the
   6 map, I can really just use null keys or a marker object.
   7
   8 ## 14:09
   9
  10 No wonder no nodes were ever red, since the color default to null, basically
  11 just black.
  12
  13 ## 15:58
  14
  15 So calling a method requires that temporary registers are saved somewhere. Any
  16 arguments to be passed are placed in the argument registers. If an argument
  17 is not temporary then that also must be saved. Due to my previous ruling of
  18 forcing locals to always be up to date, locals do not have to be saved, only
  19 temporary registers that are on the Java stack which use temporary
  20 registers. A such, the minimum stack space needed for a method is the number
  21 of local variables which are available. So then this means that local variables
  22 are copied on the call and also passed as arguments to be stored in local
  23 variables on the stack for exception handling. Basically since locals must be
  24 stored on the CPU's stack for exception handling (so they can be restored by
  25 the exception handler, or some other jump target), at the start of every method
  26 I will need to generate code that copies the input arguments to these
  27 positions. The number and type of input arguments are always known however.
  28 This may be the simplest route to take, although there will be a loss of speed
  29 due to storing values in memory. However, the locals would operate on an
  30 entirely copy on write mentality. Then this also means that saved registers are
  31 mapped to local variables and the initial arguments are just saved. However if
  32 the input argument registers are considered temporary then their values can
  33 just be copied to the saved registers which are then mapped to local variables,
  34 written to the stack, and the temporaries cleared. This would be a bit of a
  35 shuffle however.
  36
  37 ## 16:08
  38
  39 The copying and shuffling can be done right after the arguments are primed and
  40 the first instruction point placed after the shuffle code.
  41
  42 ## 17:35
  43
  44 Although it will be slightly shuffled, because I should have the remaining
  45 arguments first. This way I can still conform to the calling convention in
  46 case I ever need to call libraries.
  47
  48 ## 18:21
  49
  50 For the LUI, I can cheat by making a vt100 interface that just uses
  51 `System.out`. I can then additionally work on Squirrel Quarrel and have for
  52 example AIs battling each other. Although I would be unable to play I could
  53 use the basic interface to implement a few other things however. Also with the
  54 plan for LUI interfaces, I can even have a LUI interface which implements the
  55 LCD UI from MIDP 3 potentially. I suppose that I would like these interfaces
  56 to be visible via the service loader, however this basic interface should
  57 have a very low number so that it is chosen last.
  58
  59 ## 18:51
  60
  61 Then with the LUI service displays, when it comes to different operating
  62 systems I can have differing backends. I suppose for sanity that the display
  63 service will implement a console of a given size with attributes. Then the
  64 display service just literally needs a redraw or a draw command that is called
  65 that performs the actual work. This way the actual implementing code is kept
  66 as simple as possible. Pretty much every display device that I know of uses
  67 a cell based interface.
  68