[RFC] opengl_dynamic_nci branch

[Peter Lobsinger]

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?  In
> other words, the machine you install Parrot on will need to have all the
> build tools on it, just like the machine Parrot was built on?  (This sounds
> like the Inline:: family of modules in Perl 5.)  If so, this will be a nice
> short-term solution (which is great, we need one), but in the long term
> we'll still need to implement a solution that doesn't require a C compiler
> at runtime.

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.

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.

> My other question here is if there is any caching done?

You can look at the intended use case as a form of caching.

>> * no need to link parrot against a frame generation library (jit based
>> or otherwise)
>
> Whether we write it ourselves, or we use an existing solution, we will need
> to do this at some point ....

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.