• Gor Gyolchanyan (37/37) Nov 07 2011 I was designing a lightning-fast generic callback mechanism (to be

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

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.