assets/developer-notes/stephanie-gawroriski/2017/08/13.mkd

   1 # 2017/08/13
   2
   3 ## 12:46
   4
   5 I am thinking maybe `Variable` is going the wrong way. It has a type but I
   6 think it might be better if it was typeless, then I could also have a typed
   7 variable which is a `Variable`. Some operations use the type, while others
   8 do not. But do they extend each other and can be used interchanged? Well in
   9 most cases I would say yes, but `Variable` and `TypedVariable` would have
  10 a kind of weak `equals()` since if one was the other kind they would only
  11 compare their index. But if two were typed and they should be used in the
  12 concept of an index, then comparison would fail. So I need this
  13 distinction.
  14
  15 ## 21:04
  16
  17 Ok, so I need to take a look at `FragmentBuilder`. I want something which
  18 can be debugged and extended in special fasion to allow for architecture
  19 specific things. Right now `FragmentBuilder` is `final` and constructed
  20 by the binary when it needs to output something. What I really need is an
  21 interface which can go on top of one that can provide machine specific
  22 things. `MachineCodeOutput` does not take a `FragmentBuilder` for the base.
  23
  24 ## 21:42
  25
  26 Ok, so I think I just need a better way to create `Fragment`s. Basically
  27 they are appended through a section. But in reality fragments kind of just
  28 sit there and have things associated with them. Maybe this can work. Basically
  29 my idea is to have it where `MachineCodeOutput` is not given a fragment output
  30 it instead makes its own, where it can do whatever. `FragmentBuilder` will in
  31 essence not be linked to a `LinkerState` and acts standalone. It could also
  32 be non-final so it can be extended. This would give be a bit more freedom with
  33 `FragmentBuilder`. Then `MachineCodeOutput` can be made into an interface and
  34 I could have a special `MachineCodeOutputFragmentBuilder` or maybe just a
  35 short `MachineCodeBuilder`. This would be a `FragmentBuilder` but one with all
  36 the needed machine code specific stuff, which also works with the JIT and
  37 such. At least to the JIT itself, the `MachineCodeOutput` it uses, it would
  38 not use it a `FragmentBuilder`. All of the `MachineCodeOutput`s that exist now
  39 take a `FragmentBuilder` anyway. Then when it comes to debugging, there can
  40 be an interface to debug things. Basically this makes it so that the
  41 `FragmentBuilder` can have architecture specific things without straying
  42 farther from the base class. As for future replacements for instructions, I
  43 can have a slightly stronger means to generate them.
  44
  45 ## 21:48
  46
  47 The `FragmentBuilder` really does not care what section type it is in until
  48 it is built. So decoupling is the way to go.
  49
  50 ## 22:11
  51
  52 This is getting complex and confusing. I think the generation pipeline at
  53 least when it comes to the basic blocks is rather ugly. This makes me then
  54 wonder if `ExpandedByteCode` is needed to be implement by sub-interfaces.
  55 Well it should be for ones that do optimize.
  56
  57 ## 22:13
  58
  59 I do have the `ExpandedBasicBlock`, but I wonder if I can simplify that in
  60 a way. I mean what I have currently does work out, but it does not seem
  61 elegant at all, like it is a giant mess.
  62
  63 ## 22:14
  64
  65 It also seems rather error prone too. Like I do not want the JIT to be
  66 messed up due to some implementation issues with regards to how the classes
  67 work together. I think I should simplify it greatly. I really just need a
  68 single class for the most part. Also the `expanded` and `trans` packages
  69 are very alone, but they are in other projects so I will just keep them
  70 there being alone. But to duplicate the current functionality of basic
  71 blocks, instead of creating a new object I will just have a mark that says
  72 "from now on, everything is in this basic block". This could be completely
  73 disregarded by the expanded handler. I think I could also do with a rename
  74 of sorts, basically the translators are really just a pipeline that can do
  75 whatever. But my current goal will be to figure out a new package name and
  76 class name: perhaps `pipe` which combines `trans` and `expanded` since
  77 they are effectively the same package. Then there will be a single
  78 interface called `ExpandedPipe` which uses the functionality of the class
  79 `ExpandedBasicBlock` but with an extra method for the singular usage of
  80 `ExpandedByteCode`. `ExpandedByteCode` is basically a filler class anyway.
  81
  82 ## 23:09
  83
  84 Ok how instead of that interface I made in `arch` that is really long, how
  85 about there is an interface in the binary which can be used to write a new
  86 section when the machine code is closed. Basically, the `MachineCodeOutput`
  87 is given this interface which then tells the binary to get said section
  88 added using a binary specific means according to the `JITConfig`. So the
  89 machine code output could choose any means it wants to write native code
  90 either extending a `FragmentBuilder` or doing another thing.
  91
  92 ## 23:31
  93
  94 Ok, so this refactor makes things a bit simpler and easier to work with. Going
  95 to eat some food. After that would be getting resources being added to the
  96 binary working again, then moving back into code generation. At least with
  97 interfaces it seems much better now for the most part.