kobalicek / mpsl Goto Github PK

I spent quite some time foraging today to find asmjit and mpsl. This is certainly close to what I had in mind for some numerical and pixel processing, having some background in GPU shaders. I'm not a CPU assembly programmer, so it's a little daunting to target asmjit directly, and ideally our tools could accept user-provided C-style expressions, ideally assignments to multiple variables. A couple of broader questions in terms of goals for MPSL:

1. Is there potential to harmonize more closely with C++ types such as int8_t/char, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t and uint64_t? (If particular types are not natively available it's fine if they're simply not supported on that platform, IMHO)
2. It would be nice to have both C-style casting and C++ constructor style casting such as float(4) or uint64_t(0)
3. We'd need to be able to query MPSL for the variable names, in order to provide the types of those variables. As a workaround we can provide a potentially large list of possible variables, hopefully there isn't a significant downside to that approach.
4. Ideally we'd be able to do constant array indexing and/or dot notation into variables to bind vector data such as complex numbers or RGB tuples to MPSL at compile time. Such as color[0] or color.x
5. First-class 2D, 3D, 4D vector and matrix support with GLSL-style swizlling (pos.xxy) would be nice, eventually.
6. Our data is struct of arrays rather than array of structs, ideally we could bind each parameter as a pointer and a byte-increment for incrementing and JIT code for evaluating large batches of points/pixels/items.

Aside from this particular application we have in mind, best wishes with MPSL. I do think there is room for a light-weight C-like JITable CPU-friendly shading style of language, aside from things like Julia and GLSL.

This is a very interesting project. After a simple test, the generated ASM is not very accurate. I see that you haven't updated it for a long time. Can you expect to continue