01:56 ilbot3 joined 03:06 ZofBot joined 03:07 ZofBot joined 05:45 AlexDaniel` joined 05:49 AlexDaniel` joined 06:31 brrt joined
brrt good * #moarvm 06:41
Geth MoarVM/jit-expr-optimizer: a4b3e25c9f | (Bart Wiegmans)++ | 5 files
Remove op_info pointer

The op_info pointer is always going to be identical to that which is loaded from the MVM_jit_expr_op_info function, which is itself just a constant table lookup. So there's no need to keep it arround.		 06:44
brrt this was actually the least important problem i had 06:49
06:57 domidumont joined 07:06 domidumont joined 07:37 brrt joined 07:39 AlexDaniel` joined
brrt i don't know if i already told you, but i decided that it is probably the best idea to extend the expr template compiler to protect against conditional-use-before-unconditional-use 07:40
08:03 JimmyZ joined 08:06 zakharyas joined 08:14 zakharyas joined 09:07 zakharyas1 joined 09:09 SourceBaby joined 09:36 zakharyas joined
samcv good * brrt :) 09:51
brrt hi samcv 09:57
oh, part of what i still wanted to say, is that if i want that, i'll need a separate stage between macro expansion and name substition in the template compiler 10:03
samcv brrt, which JIT documents are up to date? 11:18
ir.md, overview.org, runtime.md, tiles.md, todo.org
which ones or possibly all of them? 11:19
brrt overview.org is most up to date 11:20
actually, all of them, except tiles.md
samcv ok
i will add those to the current docs list 11:21
brrt todo.org is arguably not a 'document' per se
eh, not documentation
samcv that's fine 11:22
11:23 zakharyas joined
Geth MoarVM: 9a0ad37a40 | (Samantha McVey)++ | docs/README.md
Update docs/README.md with links to current documentation

Since the new JIT expression engine and overview are current, they should be added to README.md.
Also add the Release Guide and the Changelog as well.		 11:30
MoarVM: 3c0a318157 | (Samantha McVey)++ | docs/README.md
Fix link to docs/jit/ir.md in docs README.md
 11:33
samcv yay!
brrt \o/ 11:46
11:56 AlexDaniel` joined
samcv heads off to bed & 11:58
lizmat night! 11:59
brrt good night samcv 12:05
lizmat is MoarVM a register based VM ? 12:13
news.ycombinator.com/item?id=15549265 # reason I'm asking 12:21
feels like that is referring to Parrot, rather than MoarVM
brrt yes, MoarVM is register-based 12:34
Zoffix AFAIK yeah. It got registers and I recall brrt I think in the past saying register VMs are good or
irclog.perlgeek.de/moarvm/search/?...q=register
brrt I don't want to go into hackernews 'debates' at any rate 12:35
but, register VMs have a few advantages
Zoffix :)
brrt it might be referring to parrot, eys
so the difference is basically this; 12:36
in a stack vm, your referring to a 'stack', so that's an ever-changing memory base
your stack top is always moving about
all operations 'implicitly' take stack operands 12:37
and return them also implicitly
this means, among ohter things, that your compiler must guard against stack overflows and underflows 12:38
and indeed, the notion that at the end of a subroutine, the stack has to be at the same spot it left off from
i.e.: for (1..10) { push }; pop; # this is possible but illegal 12:39
lizmat brrt: thanks for clearing that up
brrt np :-)
it also means that for a JIT, you have to give a name all the stack positions you might see in a program run. and make sure you're referring to the correct one while working 12:40
not impossible to do, but not the nicest thing either
it also means that for a GC, you're going to have to be either imprecise, tag your pointers, or have a 'gc safe points' for which you make maps that give you the layout of the stack at that point 12:41
and that also sucks
or, you're going to have boxed everything
i.e. you can't just have a native integer on the stack if you don't know at every point that you might need to inspect it, what operand that actually is 12:42
Zoffix How do you know all of this stuff? Got books to recommend? 12:43
brrt ehm..... 12:44
i dunno, actually. experience i guess
which means that i might be wrong about some aspects
i did read 'Engineering a compiler' by… well, there's only one famous book by that name
Zoffix :}
brrt and Aho's compiler
s
Zoffix adds those to the list :) 12:45
brrt but to make a long story short.. I think register vms are the way to go :-)
and i also think they make writing a JIT easier, because every local value already has a 'true' name
so there's a whole bunch of analysis that you just don't have to do
12:55 zakharyas joined 13:12 zakharyas joined
dogbert17 .seen timotimo 13:48
yoleaux I saw timotimo 08:59Z in #perl6: <timotimo> a look-around assertion
14:05 AlexDaniel` joined
dogbert17 any cool c-programmers around? 14:32
my question is: how can we be certain that 'test' is not null at github.com/MoarVM/MoarVM/blob/mast...ard.c#L411 14:34
dogbert17 is getting a SEGV on line 411 while running /spec/S12-attributes/undeclared.t
Zoffix I'm an uncool c-programmer, but is `test != NULL` a thing maybe? 14:36
eater `!test` even 14:37
eater is also uncool
dogbert17 as is I
I guess null should be tested for or there's a statement missing whose purpose is to retrieve 'test' 14:40
here's what I ran: while MVM_SPESH_NODELAY=1 ./perl6 t/spec/S12-attributes/undeclared.t; do true; done 14:43
15:18 brrt joined 15:41 brrt joined 16:36 buggable joined 17:07 domidumont joined 19:25 evalable6 joined 20:29 evalable6 joined
samcv i want to add a function called MVM_reg_get_debug_name similar to MVM_6model_get_debug_name 20:37
but am not sure where to put it. MVMreg* are defined in src/core/interph 20:38
interp.h that is. i also want MVM_string_get_debug_name though that will be easier to find a place for
hmm 6model may be a good place to put both? 20:39
well not sure about MVMreg since it doesn't have its own file and is defined in interp.h 20:40
jnthn samcv: What could the functions do? 20:42
samcv return the name of the item
jnthn "the item"?
samcv MVM_STRING_GRAPHEME32 or MVM_reg_uint32 etc
atm many of the errors don't tell you what it encountered 20:43
returns a string of the type name
jnthn Hm, example of an error to improve?
samcv so instead of "Unknown lexical type encountered while building context iterator"
"MVM_reg_uint8 lexical type encountered while building context iterator"
and it will say Unknown if it's actually "unknown" and not just not handled in that function 20:44
jnthn Ah
I guess it'd be "Unexpected uint8 lexical encountered..." etc.
That one I'd probably put in interp.h though
samcv ok 20:45
and leave out the reg part?
jnthn I guess MVM_reg_type_name is fine enough 20:46
Matches the consts
samcv cool 20:47
damn getting multiple definitions error 20:48
even though it's only in interp.h 20:49
things must be including interp.h multiple times
hmm not seeing that grepping the source though 20:50
jnthn, any clue how to fix that? 20:59
i just added MVM_reg_get_debug_name to interp.c 21:00
jnthn No, that sounds odd :S 21:04
samcv having moar.h #include foo/bar.h and having foo/bar.c #include "moar.h" should be ok right? 21:05
ah i forgot to declare it static :) 21:06
jnthn Yeah
oh :)
Geth MoarVM: samcv++ created pull request #732:
Include the type of unhandled register in error messages		 21:34
samcv jnthn, if i do `my int8 $var = 255';` `"$var";` in REPL i get an error btw 21:44
Geth MoarVM/jit-expr-optimizer: 8d0bdb4b68 | (Bart Wiegmans)++ | src/jit/optimize.c
Fix C89 compatibility

Can't declare a variable after statements		 21:45
samcv not sure what's going on
also doing `my uint16 $var = 255'; "$var"` also gives an issue in repl (doing first and second line separately) 21:50
jnthn samcv: Probably some NYI somewhere or other 21:52
Waht's the error?
samcv lexical type encountered while building context iterator # before adding it to MVMIter.c
but after i do, or for types already there (intx types) 21:53
Unhandled lexical type 'int16' in lexprimspec for '$var'
this is the more updated error
should be Unhandled lexical type in lexprimspec for '$var' for you if you assign to `my int16 $var` and then on the next line do `say $var` 21:54
jnthn Ah, hmm 21:55
samcv here's the backtrace if i make it an oops gist.github.com/samcv/043f8254281c...8e92b1df66 21:57
not sure if it should be making an iterator, it probably should
Geth MoarVM: samcv++ created pull request #733:
Handle unsigned types to switch in MVM_iter()
samcv anyway making a PR for you to look at handling those types in MVM_iter() 21:58
though still shows the error somewhere else, showing the same error as using the signed int types do
jnthn Will take a look, though tomorrow 'cus I'm super tired 22:02
'night o/ 22:03
samcv np
night o/
23:05 evalable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!