12:46
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.
21:04
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.
21:42
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.
21:48
The FragmentBuilder really does not care what section type it is in until
it is built. So decoupling is the way to go.
22:11
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.
22:13
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.
22:14
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.
23:09
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.
23:31
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.