07:31
Sunday was a stressful day, so yesterday I spent the time healing up. So hopefully I can get some work done today.
09:00
When it comes to generation, my plan for the compiler was to have it segmented
into interfaces that provide specific functionality. This would allow the most
patchable code generator which may be needed for specific systems. Essentially
there would be a basic PowerPC generator interface. Thinking about it, with
the service loader I would then not require that the compiler bits are even
extending off each other. So essentially the compilers would be sorted by
architecture (and their variant). The base class would be a final
SSJITProducer
. The producer would be given interfaces which all extend from
a base interface. Following this, the producer factory would have a
contributing generator fragment which implements a number of interfaces for
added functionality. When the generator is called to generate some code, it
will then call through premapped interfaces that perform actual code generation
for the most part. Then this way there can be a base PowerPC provider. Then
there would be a Linux variant for PowerPC (likely sysv). The Linux variant
would just extend SSJITProducerFactory
for the factory and the actual
generator with its implemented interfaces would implement SSJITProducer
.
09:09
Actually, the producer is final so the factory would provide the set of interfaces. The interface set would then have a bind to the given producer. This way when something needs to be done, it can call into the given producer so that if there is another potential variant that it can be handled properly.
09:14
These interfaces would be called functions. I can either share them between or have them completely alone. Being alone would add to the memory cost and increase garbage collection costs, however it would simplify code generation because each instance of a function could have its own set of variables.
09:18
Then this means that SSJITProducerFactory
is renamed and turned into
SSJITFunctionFactory
.
09:20
So this also means that in the event of floating point, I can have a fallback software floating point factory which can actually be enforced. So even if the PowerPC function set would natively support floating point, the factory can just be given a software floating point function that has higher priority.
09:22
For 8-bit and 16-bit systems, I can even have a function that handles higher bit operations by wrapping them in the smaller operation functions. So instead of rewriting 32-bit/64-bit math functions in each set of functions, I only have to do it once. However, I could just have a base class that handles these operations natively.
09:34
Also, this means that CPU variants can more easily be supported. Very old PowerPC CPUs do not support SIMD operations. So on variants that support AltiVec for example, I can have a standard PowerPC function returned along with an AltiVec function.