So I've been kicking around the idea for a simplified NCI dispatch mechanism for Parrot. The upside is that it would be versatile and you wouldn't need to write out a large list of NCI signatures before the build. The downside is that it would be written in assembly and highly platform dependent. Here's some pseudocode for the C part of the dispatcher:
void nci_dispatcher(...) {
void * args_array = malloc(sizeof(void *) * num_of_args);
foreach (args) {
args_array[i] = args[i++];
}
ret = _asm_dispatch(c_func_ptr, args_array);
}
Here's the part for the assembly dispatcher:
__asm_dispatch:
pop args_array
pop c_func_ptr
mov ecx, num_args
loop_top:
je ecx, 0, end
push args_array[i]
inc i
dec ecx
jmp loop_top
end:
call c_func_ptr
pop eax
ret
Now, I'm sure that I've criss-crossed my MASM and GAS syntaxes, and for clarity I definitely didn't properly declare all my variables. Also, I didn't account for floating point return values, which certainly wouldn't be coming from the same place as an INTVAL or pointer return value would. I don't care because it's pseudocode after all.
The downside to this approach is that the _asm_dispatch function would have to be written in platform-specific ASM code, which would be a nightmare to do with our current config system and our list of supported platforms. We would need a different version of the code for each supported assembler on each platform (GAS and MASM on i386 for instance). It might be required that we pre-assemble the object files and include them in the repository for people who don't have assemblers or don't have the few assemblers that we're supporting.
Anyway, it's an idea that I had to help simplify things. I think it has some merit, even if it's going to be difficult to implement and maintain. What I'm sure would happen is that we would need to maintain the current NCI system as a fallback anyway for systems where this approach isn't possible or feasible. And since maintaining the two systems isn't a good idea in the long-term, this idea is probably dead on arrival.
This sounds very vaguely like what Mozilla did with XPCOM, except at compile time. I recall hacking SGI MIPS (IP22?) assembly to try to get Mozilla to run on my O2 almost a decade ago (ouch). Yes, the platform-specific bits can be a show-stopper, even if they're tiny. On the other hand, is it possible to leverage the Mozilla work? I really have no concrete way to judge the usefulness of that idea, though.
