[RFC] opengl_dynamic_nci branch

Geoffrey Broadwell 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  
>> loaded?
> 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 mailing list