digitalmars.D - user-space calling conventions
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Nov 07 2011
I was designing a lightning-fast generic callback mechanism (to be used in dynamically modular software architectures) using pointer trickery and parameters being passed in a compile-time generated struct by pointer to bring all functions' ABI to a single void* taking functions (internally). It's such a pain to generate a structs at compile-time, which would encapsulate function parameters with respect to their storage classes (ref, out, lazy), which change their internal representation. I've made prototypes of it, but it's painful (especially debugging string mixin code). It's even more painful to write typeless wrappers for function calls, that take a void*, interpret it as a pointer to a struct, that was generated from the function's parameter tuple, pass it to the function and return the result (if any) as a Variant (later versions will replace Variant with something faster). The generated structs will aggregate the type of it's target function and the type-check on the call site will be done against the entire function signature at once, instead of each parameter individually, making the type-check very fast. This is a lot of tedious and dangerous work to achieve ABI-level optimized typeless (yet type safe due to the check as described above). Then I Imagined how easy it would be if i could use my own calling convention, so that i don't have to adapt typeless binary-uniform calling convention to D's (perfectly sensible) calling convention. The function-part isn't too hard to do, because I can make my caller naked and implement my own ways of reading the parameters. The problem is the way the callback is supposed to be defined. Currently, I have no way to define functions with my calling convention without taking delegates, wrapping them into asm blocks, where i pass the parameters to them. This is not only tedious and dangerous, but also very slow and defeats the purpose of this calling convention. I'm not going to propose any additions to the language yet, so instead I'll ask whether anyone knows how can I overcome this limitation? The resulting mechanism could be used to implement very fast library-based dynamic typing facilities for D.
Nov 07 2011