|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
02:21
MasterDuke left
02:38
avar left,
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
02:39
p6bannerbot sets mode: +v avar
03:04
lizmat left
03:12
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
03:14
ZzZombo left,
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
05:02
ZzZombo left
05:04
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
06:02
lizmat joined,
p6bannerbot sets mode: +v lizmat
06:27
patrickb joined,
p6bannerbot sets mode: +v patrickb
06:29
domidumont joined
06:30
p6bannerbot sets mode: +v domidumont
07:06
robertle joined,
p6bannerbot sets mode: +v robertle
08:14
zakharyas joined
08:15
p6bannerbot sets mode: +v zakharyas
08:51
pmurias joined
08:59
pmurias left
09:12
pmurias joined,
p6bannerbot sets mode: +v pmurias
|
|||
| pmurias | any issues with github.com/MoarVM/MoarVM/pull/947 or just lack of tuits to merge that? | 09:13 | |
| it's an op that removes the need for having an nqp::p6decodelocaltime extopt | 09:14 | ||
| lizmat | pmurias: atm it seems to have conflicts ? | 09:18 | |
| also, this week, jnthn will be enjoying a well deserved holiday | |||
|
09:34
lizmat left
09:43
brrt joined,
p6bannerbot sets mode: +v brrt
|
|||
| brrt | \o | 09:47 | |
| nwc10 | o/ | 09:48 | |
| brrt | ohai nwc10. is there still a perl conference going on now? | 09:49 | |
| nwc10 | act.perl-workshop.ch/spw2018/ says Dates: Friday 7th September 2018 and Saturday 8th September 2018 | 09:50 | |
| brrt | so.. no | ||
| ok :-) | |||
| nwc10 | oslo.pm/npw2018/ says Nordic Perl Workshop 2018 will be held in Oslo at Teknologihuset, 6 - 7 September, 2018. | ||
| so, no, not that I'm aware of | |||
|
09:59
ZzZombo left
10:13
brrt left
10:36
brrt joined
10:37
p6bannerbot sets mode: +v brrt
|
|||
| brrt | we need much better, much more direct JIT testing | 11:08 | |
| i mean... i'm adding templates for trunc_i. Will they ever be called? | 11:09 | ||
|
11:33
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
11:36
zakharyas left
|
|||
| pmurias | brrt: how do you imagine better testing to look like? | 12:31 | |
| brrt: it seems like a common problem with compilers, you could test the output directly but when you change things you need to update the tests | 12:32 | ||
| brrt: measuring template usage coverage could maybe help | 12:34 | ||
| brrt | it's a good question | 12:47 | |
| well, ideally, i'd be able to write a tiny script representing moar bytecode, have it JIT compiled directly, run it, and assert things about it's output | 12:48 | ||
| wouldn't work for all cases, especially when stack walking / dynamic lexicals are involved | |||
|
13:11
zakharyas joined,
p6bannerbot sets mode: +v zakharyas
|
|||
| Geth | MoarVM: 891d5c02ec | (Bart Wiegmans)++ | 2 files [JIT] Implement truncation via unsigned cast Signed truncate isn't really well defined, I think. |
13:29 | |
|
13:38
ZzZombo left
13:39
ZzZombo joined,
p6bannerbot sets mode: +v ZzZombo
|
|||
| timotimo | huh. | 13:49 | |
| brrt | i mean, what even is the meaning of signed truncate | 13:50 | |
| timotimo | well, we're using this to support smaller register sizes | 13:52 | |
| it'd be weird if we only could support uint8 uint16 uint32 native ints in the jit | |||
| but not int8, int16, int32 | 13:53 | ||
| brrt | oh, but that doesn't make any difference, is my point | 14:04 | |
| anyway, differently sized registers are probably a mistake? | 14:05 | ||
| differently sized values are fine | |||
| timotimo | well, the registers are the same size | ||
| that's why we need truncate and extend ops | |||
| brrt | let me ask you: how are you going to signed-truncate the number 1000 to 1 byte | ||
| and how are you going to signed-truncate -1000 | 14:06 | ||
| timotimo | i guess it really depends on the operation that precedes it? | ||
| brrt | hmmm | 14:10 | |
| no, i'm really just saying; signed-truncate is a nonsense idea. It cannot be done | 14:11 | ||
| it's fine to want to use and treat the resulting truncated numbers as signed | |||
| and if a number fits into the unsigned space, that's fine as well | 14:12 | ||
| timotimo | OK | ||
| brrt | I'm guessing you could say that you'd zero-extend the original number then assign the highest bit of the bigger number to the lower number | 14:13 | |
| so it's easy to truncate-signed a -128 short to -128 byte | |||
| that's just 0xff80 to 0x80 | |||
| but, for instance, 0x180 would also be truncated to 0x80, even though 0x180 is positive | 14:15 | ||
| so what you could say as semantics is that you preserve the sign; that would make 0x180 truncate to 0x0 | |||
| is that the right thing to do? | |||
| timotimo | sorry, i'm too headachy to think this through | 14:16 | |
| brrt | fwiw, C will downcast 0x180 to 0x80 | ||
| i'll not bother you then :-) | 14:18 | ||
| pmurias | brrt: running small chunks of moar bytecode under forced jit and seeing if the print out the right stuff seems sane | 14:21 | |
| brrt: the tests could even construct the bytecode as MAST instead of having hardcoded bytecode | 14:22 | ||
| brrt | right | 14:31 | |
| i'm thinking of something even more low-level | |||
| but yes | |||
| timotimo | check the assembly? | ||
| data flow analysis at the register/memory level? | 14:32 | ||
| brrt | no, not so low level | 14:33 | |
| although, would be cool too | |||
|
14:53
robertle left
15:15
robertle joined
15:16
p6bannerbot sets mode: +v robertle
|
|||
| pmurias | brrt: even more low-level than bytecode level? | 15:21 | |
|
15:22
patrickb left
|
|||
| pmurias | brrt: for matching generated stuff something like this jestjs.io/docs/en/snapshot-testing could be useful | 15:24 | |
|
15:25
brrt left
|
|||
| japhb | brrt: "signed truncate" makes sense to me, in the context of "small value residing in large register" -- it would be a standard truncate followed by a sign extend. | 15:33 | |
|
15:47
domidumont left
16:32
brrt joined
16:33
p6bannerbot sets mode: +v brrt
|
|||
| brrt | japhb: actually, that would make sense to me as well; there are two vagaries though | 16:38 | |
| mostly, the last bit of the truncated value isn't the sign bit of the original value | 16:39 | ||
| which leads to a): a negative number when truncated that wasn't negative orignally, and a positive number truncated that was negative originally | 16:40 | ||
|
16:47
robertle left
|
|||
| japhb | brrt: Sure, but that's the difference between standard truncate and "signed" truncate -- you're specifically accepting different failure modes for each. (0x0180, 0x8001, and 0xFFFF all will flip sign on one or the other, but you're choosing which behavior you want based on which truncate variant you choose.) | 17:58 | |
| brrt | I agree. What I'm not sure about, is whether this is what anyone expects | 18:05 | |
| I mean, you try this in C, you get unsigned truncation | |||
| also, if we consistently treat a small integer as such, then extend it to signed/unsigned as requested, this will never be a problem | 18:07 | ||
| and, our current implementation is effectively an unsigned truncate, I think | 18:08 | ||
| m: nqp::say(nqp::trunc_i8(384)) | |||
| camelia | ===SORRY!=== Error while compiling <tmp> Could not find nqp::trunc_i8, did you forget 'use nqp;' ? at <tmp>:1 ------> nqp::say(nqp::trunc_i8(384)⏏) |
||
| brrt | nqp: nqp::say(nqp::trunc_i8(384)); | ||
| camelia | No registered operation handler for 'trunc_i8' at gen/moar/stage2/QAST.nqp:1635 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op) from gen/moar/stage2/QAST.nqp:6057 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_nod… |
||
| brrt | that's.. huh | ||
| nqp: my int $x := nqp::trunc_i8(384); nqp::say($x) | 18:10 | ||
| camelia | No registered operation handler for 'trunc_i8' at gen/moar/stage2/QAST.nqp:1635 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op) from gen/moar/stage2/QAST.nqp:6057 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_nod… |
||
| brrt | nqp: nqp::say(nqp::trunc_u8(384)); | 18:12 | |
| camelia | No registered operation handler for 'trunc_u8' at gen/moar/stage2/QAST.nqp:1635 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op) from gen/moar/stage2/QAST.nqp:6057 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_nod… |
||
| brrt | confusing | 18:19 | |
|
18:22
robertle joined
18:23
p6bannerbot sets mode: +v robertle
18:24
zakharyas left,
brrt left
20:06
lizmat joined
20:07
p6bannerbot sets mode: +v lizmat
20:15
ggoebel_ left
|
|||
| jnthn | The current compilation model is that we always extend natives to perform operations on them and truncate at the point of storage. | 20:20 | |
| So all calculation takes place at fixed width | |||
| And the trunc/extend are inserted by the compiler | |||
| And need to have a correctly sized destination | 20:21 | ||
| See the coercion method in the QAST -> MAST compiler | |||
|
20:26
pmurias left
20:31
ggoebel_ joined,
p6bannerbot sets mode: +v ggoebel_
20:34
Kaiepi left
20:35
Kaiepi joined,
p6bannerbot sets mode: +v Kaiepi
20:39
Kaiepi left
20:42
Kaiepi joined
20:43
p6bannerbot sets mode: +v Kaiepi
20:49
lizmat left
21:00
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
23:05
lizmat joined
23:06
p6bannerbot sets mode: +v lizmat
23:45
robertle left
23:49
MasterDuke left
23:57
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke
|
|||