On Feb 12, 2010, at 15:30, Peter Lobsinger wrote:
On Fri, Feb 12, 2010 at 2:06 PM, Geoffrey Broadwell <[email protected]
> 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
code.
Just another point in the solution space, I guess.
-'f
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
