[RFC] removing library NCI signatures from core
julian.notfound at gmail.com
Wed Feb 17 16:02:58 UTC 2010
> The 2 major ways to extend parrot, dynpmcs and dynops, already need a
> C compiler.
Yes. So adding a supposed NCI that accomplish essentially the same
mission is pointless.
> But static signatures have a cost of requiring the interpreter to haul
> around a hash (~400 elements) of thunks that are hardly ever used.
> These bloat both the gc pool and the code size. For users that don't
> need it, why have it?
Yes, static signatures are costly and incomplete. What we need is a
way to generate dynamically, like the old jit tried to provide.
>> Fine, but in that case let's keep the current way until we have that
>> other new way.
> A number of people seem to believe that this better way is a runtime
> thunk generator. That won't work everywhere. There will always be some
> architecture to which whatever ffi library you use has not yet been
There are also platforms without symbolic links, but we provide
support for that.
>> I like to be able to access any public function in any dynamic library
>> of the system from pure pir, hand written or generated, without
>> compiling and installing anything, even with a parrot buit before that
>> library existed. That's what I believe a Native interface is.
>> Otherwise is just an extension mechanism.
> That mis-characterizes what NCI in parrot is right now. NCI in parrot
> currently only works for a narrow set of libraries that have been
> registered in config/gen/call_list/misc.in. If the library you want
> isn't there, and you've created bindings that "work", they only work
> by accident.
That's no very exact. We don't need to have any library registered, we
just need the function signatures. And is not an accident, the now
defunct jit system fully allowed that in the platforms that used it.
More information about the parrot-dev