RPC and Dynamic function call

[grauzone]

Denis Koroskin wrote:
> I thought about that, too. And then I thought:
> 1) you can move deserialization out of this method (my serializer 
> doesn't need type hints to deserialize data).
> 2) you can reuse the trampoline for those functions that have same type 
> of input argument (less bloat)
> 3) you can create a trampoline for each type, not for each set of types 
> (N trampolines instead of N! in worst case)

That would be interesting.

>> Wow, I'm surprised that this works. Actually, I'd *like* to do it this 
>> way, but the code is completely compiler and platform specific. Maybe 
>> it also depends from the compiler code generator's mood if it works. 
>> And if you want to deal with user-define types (structs), you're 
>> completely out of luck.
> 
> Why? It works well with custom structs, too. There is a test case 
> attached, try to run in, it should work.

And you have to special case this in very awkward ways. What if a struct 
is larger than 8 bytes? This whole approach is so shaky, I don't trust 
it one bit.

It would be another thing if all this would be part of the runtime core 
(and the compiler implementer makes sure it works).

> One of the reasons I posted the code is because I'm not sure it is 
> correct and that it will always work (on a given platform).
> I'm not an ASM guru, so comments would be invaluable.

Neither am I, but I guess it will be very hard to emulate calling 
conventions on non-x86 32 bit platforms. E.g. on amd64, several 
arguments are passed in registers (AFAIK).

In any case, you trust the compiler not to insert additional code and 
not to touch the stack. Maybe it works with dmd, but what about ldc or gdc?

Well, let's see if anyone can test it...

Now, this doesn't really matter. You can always rewrite it as asm code. 
And in asm, you definitely can do such dynamic calls.

One issue is that you need the static signature of the RPC target for 
type checking. What are you going to do about this?

> I updated code to work with Tango, could anybody please try to run it on 
> Linux x86/x86_64 (ldc)? An output should be:
> 516.00
> 13.00

Segfaulted on x86 32 bit / Tango / Linux.