github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine I've read here a couple of times (since people keep bringing it up) that LLVM JIT wouldn't be nearly as simple and/or wouldn't work as well as people assume. Looking at the docs I do get the impression that integrating LLVM is hardly straight forward. 09:10
This however looks quite possible - even easy: gcc.gnu.org/onlinedocs/jit/intro/t...ial04.html 09:12
And the optimizations it does are quite fascinating
In other news: explicitly-manage really is a misnomer and its documentation is wrong ("If the string returned is passed to a NativeCall subroutine, it will not be freed by the runtime's garbage collector.") 10:01
It's quite the opposite actually: the GC will free the encoded string as opposed to NativeCall doing so right after the call finishes
It does give control to the user by tying the life time of the encoded string to the original string's. 10:03
nine Oh and the (undocumented) :encoding argument of explicitly-manage hasn't done anything since 2014 10:32
MasterDuke nine: saw that phoronix article too?  do you think it would be a replacement for our current jit? an alternative like ffi/dyncall? or an extra tier, like the JS VMs? 10:44
nine I do not even see a way to support explicitly-manage in JIT compled native calls
MasterDuke: I guess that it'd be quite possible to map the Lego JIT's graph to gcc JIT's and replace dynasm that way. Probably the same is possible for the expr JIT. I'm just much less familiar with the latter's implementation. 10:45
And yes, this would include a replacement for ffi/dyncall.
Major benefits would be backends for all architectures, those interesting optimizations and less code to maintain (with a drastically increased bus factor) 10:47
MasterDuke oh, i didn't realize it would remove ffi/dyncall, i was just using those as an example of something currently where we have selectable alternatives 10:53
sounds nice
nine In principle the JITed NativeCall stuff we have can replace the ffi/dyncall backends. I've just never finished it. It just supports what Inline::Perl5 needs. libgccjit would presumably simplify supporting the remaining types (like floats) 11:05
nine Now working correctly: sub take_and_free_struct_but_not_struct(StructWithStruct $s is transferring-ownership(:except<$!s>)) is native($lib) { !!! } 14:16
I've decided to only support a flat :except list and a flat :only list directly. For anything more complicated, plain old code is best to specify, i.e. :except(*.foo.bar.baz) or is transferring-ownership(:only(*.foo.bar.baz)) 14:19
Actually.... :except(*.foo) is excactly as short as :except<$!foo> 14:21
OTOH I'm not sure how to implement :except(*.foo) anyway. With information in the form of :except<$!foo> I can generate code for nqp::setmanaged(nqp::getattr($param, $param.WHAT, $attribute-name), 0) and just leave out $attribute if it machtes any exception. 14:25
With :only(*.foo) I'd generate nqp::setmanaged(nqp::call($only[0]), 0) without having to care about the actual attribute's name. 14:26
But with :except(*.foo) I'd have to generate a runtime check for if nqp::getattr($param, $param.WHAT, $attribute-name) !=== nqp::call($only[0]) which is kinda horrible. 14:27
Did I just imagine someone mentioning macros? 14:28
nine Works correctly as well now: sub return_allocated_struct_with_static_struct(--> StructWithStruct) is transferring-ownership(:except<$!s>) is native($lib) { !!! } 15:24
So what remains are really strings. Other than CStruct, CPPStruct, CUnion and CArray I cannot just give the string a managed-flag. 15:25
For strings NativeCalls' API is a bit over-simplified again. Those other types are special NativeCall types that wrap the native object. For strings we expect high level Raku objects (Str) and create the native object on the fly. 15:27
Would be easier if there was a CStr type as well. There is already a perfectly fine CStr repr even. 15:30

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!