[RFC] opengl_dynamic_nci branch
geoff at broadwell.org
Fri Feb 12 23:51:16 UTC 2010
On Feb 12, 2010, at 15:30, Peter Lobsinger wrote:
> On Fri, Feb 12, 2010 at 2:06 PM, Geoffrey Broadwell <geoff at broadwell.org
> > wrote:
>> So you will be writing C files and compiling them when OpenGL is
> This not what I meant. Sorry for the ambiguity. The intention is to
> run nativecall.pir at library make time. If you were to look for an
> analogue in perl 5, it would be XS.
Ah, I get it.
> It is still true that the library maker needs access to the same C
> compiler that was used to compile parrot, but non-trivial C-based PMCs
> already require this, so I don't consider it too much of a burden.
Sure, if you're doing it at library build, I can't imagine it otherwise.
> Some architecture/os combinations are not well supported by code
> generation libraries and some make these very difficult, if not
> impossible (using eg w^x). I consider it to be unacceptable to provide
> only degraded NCI functionality to these systems when it is entirely
> possible to provide the full offering.
> Dynamic frame generation still has advantages, but these should be
> limited to performance, not functionality.
You know, the above makes me wonder if we need a thunk *interpreter*
library. Instead of generating optimized machine code for each thunk,
it would instead simply take a signature string and a varargs list and
convert the varargs to platform-appropriate native call arguments,
perform the call, and unpack the return similarly. It would be slow,
but fully generic. I'm assuming we'd have to write one of these per
platform/compiler, but I wouldn't think it would be terribly difficult
Just another point in the solution space, I guess.
More information about the parrot-dev