I am thinking maybe Variable is going the wrong way. It has a type but I think it might be better if it was typeless, then I could also have a typed variable which is a Variable. Some operations use the type, while others do not. But do they extend each other and can be used interchanged? Well in most cases I would say yes, but Variable and TypedVariable would have a kind of weak equals() since if one was the other kind they would only compare their index. But if two were typed and they should be used in the concept of an index, then comparison would fail. So I need this distinction.


Ok, so I need to take a look at FragmentBuilder. I want something which can be debugged and extended in special fasion to allow for architecture specific things. Right now FragmentBuilder is final and constructed by the binary when it needs to output something. What I really need is an interface which can go on top of one that can provide machine specific things. MachineCodeOutput does not take a FragmentBuilder for the base.


Ok, so I think I just need a better way to create Fragments. Basically they are appended through a section. But in reality fragments kind of just sit there and have things associated with them. Maybe this can work. Basically my idea is to have it where MachineCodeOutput is not given a fragment output it instead makes its own, where it can do whatever. FragmentBuilder will in essence not be linked to a LinkerState and acts standalone. It could also be non-final so it can be extended. This would give be a bit more freedom with FragmentBuilder. Then MachineCodeOutput can be made into an interface and I could have a special MachineCodeOutputFragmentBuilder or maybe just a short MachineCodeBuilder. This would be a FragmentBuilder but one with all the needed machine code specific stuff, which also works with the JIT and such. At least to the JIT itself, the MachineCodeOutput it uses, it would not use it a FragmentBuilder. All of the MachineCodeOutputs that exist now take a FragmentBuilder anyway. Then when it comes to debugging, there can be an interface to debug things. Basically this makes it so that the FragmentBuilder can have architecture specific things without straying farther from the base class. As for future replacements for instructions, I can have a slightly stronger means to generate them.


The FragmentBuilder really does not care what section type it is in until it is built. So decoupling is the way to go.


This is getting complex and confusing. I think the generation pipeline at least when it comes to the basic blocks is rather ugly. This makes me then wonder if ExpandedByteCode is needed to be implement by sub-interfaces. Well it should be for ones that do optimize.


I do have the ExpandedBasicBlock, but I wonder if I can simplify that in a way. I mean what I have currently does work out, but it does not seem elegant at all, like it is a giant mess.


It also seems rather error prone too. Like I do not want the JIT to be messed up due to some implementation issues with regards to how the classes work together. I think I should simplify it greatly. I really just need a single class for the most part. Also the expanded and trans packages are very alone, but they are in other projects so I will just keep them there being alone. But to duplicate the current functionality of basic blocks, instead of creating a new object I will just have a mark that says "from now on, everything is in this basic block". This could be completely disregarded by the expanded handler. I think I could also do with a rename of sorts, basically the translators are really just a pipeline that can do whatever. But my current goal will be to figure out a new package name and class name: perhaps pipe which combines trans and expanded since they are effectively the same package. Then there will be a single interface called ExpandedPipe which uses the functionality of the class ExpandedBasicBlock but with an extra method for the singular usage of ExpandedByteCode. ExpandedByteCode is basically a filler class anyway.


Ok how instead of that interface I made in arch that is really long, how about there is an interface in the binary which can be used to write a new section when the machine code is closed. Basically, the MachineCodeOutput is given this interface which then tells the binary to get said section added using a binary specific means according to the JITConfig. So the machine code output could choose any means it wants to write native code either extending a FragmentBuilder or doing another thing.


Ok, so this refactor makes things a bit simpler and easier to work with. Going to eat some food. After that would be getting resources being added to the binary working again, then moving back into code generation. At least with interfaces it seems much better now for the most part.