|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
01:19
lucasb left
05:07
squashable6 left,
bloatable6 left,
linkable6 left,
notable6 left,
committable6 left,
greppable6 left,
tellable6 left,
benchable6 left,
releasable6 left,
shareable6 left,
coverable6 left,
nativecallable6 left,
sourceable6 left,
bisectable6 left,
statisfiable6 left,
unicodable6 left,
quotable6 left,
evalable6 left,
benchable6 joined,
bloatable6 joined,
squashable6 joined
05:08
notable6 joined,
linkable6 joined,
coverable6 joined,
greppable6 joined,
sourceable6 joined,
quotable6 joined
05:09
releasable6 joined,
statisfiable6 joined,
evalable6 joined,
nativecallable6 joined,
committable6 joined,
unicodable6 joined,
shareable6 joined
05:10
bisectable6 joined,
tellable6 joined
07:55
linkable6 left,
evalable6 left
07:57
linkable6 joined,
evalable6 joined
|
|||
| 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 | ||
|
10:26
sena_kun joined
|
|||
| nine | Oh and the (undocumented) :encoding argument of explicitly-manage hasn't done anything since 2014 | 10:32 | |
|
10:42
MasterDuke joined
|
|||
| 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 | |
|
11:23
Geth joined
13:56
MasterDuke left
14:06
sena_kun left
|
|||
| 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 | ||
|
14:32
lucasb joined
|
|||
| 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 | ||
|
15:39
elcaro left
17:32
zakharyas joined
17:35
domidumont joined
18:48
sena_kun joined
19:48
domidumont left
21:33
zakharyas left
23:22
lucasb left
|
|||