Open arteymix opened 7 years ago
Here's a sample of code that the generator shall target: e2036fb1275aebdcb4fe1a61ba66d35eff4634f5
The routines
subfolder will contain declarations files that the code generator will consume to populate the routines_sources
variable. It will then be piped back into the compiler to finalize the build. Vala will produce introspection data as usual that we will have access at runtime to build the computation graph.
Maybe we can simply define them in a vala file (in-place array of struct, for example). This way we avoid parsing.
I think we eventually want to move type dispatching out of the function -- that logic will be duplicated in each generated function. On the other hand, it is already generated, so we probably don't really care anyways?
How do we know sin does not support float -> double and double -> float, int ->float? (a cast is needed if the types are not supported).
Basically, we need meta-data that, for each routine, provide a set of candidates with the input/output types. Now I wonder if that exists already.
We will also need some help from the iterator to yield contiguous chunks so that we can perform vectorized operations on them.
By the way, I finished all the type transformations for Numeric-GLib. The only thing left is byteswapping.
We'll mainly rely on code generation for math and other routines.
Is there any standards for describing functions? and set of routines implementing it? Otherwise I think we could have some YAML markup to describe them.
libvala is really great for generating code and handle various cases. In particular to analyze the symbols (e.g.
Math.*
) and use the inferred type instead of dumping that into the metadata.Meson support generators, which are arbitrary program that produce sources that can then be piped back into a compiler.