github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:36 nebuchadnezzar left 00:38 nebuchadnezzar joined 00:44 squashable6 left 00:47 squashable6 joined 01:15 lizmat left, lizmat joined 01:16 lucasb left 02:59 rba left 04:16 AlexDaniel left, AlexDaniel joined 05:19 rba joined 05:22 rba left 05:23 rba joined 05:35 rba left, rba joined 05:45 rba left, rba joined 06:46 lizmat left 06:50 domidumont joined 07:03 lizmat joined 07:07 patrickb joined 07:11 lizmat left 07:51 lizmat joined 07:56 zakharyas joined 08:09 lizmat left 08:32 lizmat joined 08:42 sena_kun joined 09:32 domidumont left 09:35 brrt joined
brrt \o 09:46
nwc10 o/ 09:53
brrt I have a ... challenge? problem? design question... 10:00
The template language specifies a branching operation as a tree of branch -> test -> operands 10:01
(or: operands, test, branch sequence)
however, in emitting the branch opcode, we kind of need to know whether the opcodes where floating points, or integers 10:02
since x86 sets every so slightly different combinations of flags for floating point and integer register comparison 10:03
(it doesn't matter whether you use SSE or x87 FPU for the oprations, fwiw, although the x87 FPU has special 'internal' branching opcodes as well)
The design question is to have a nice way, that doesn't break, to transfer the type of the operands 'up' to the branch 10:05
nwc10 I don't know enough about the current code to be able to answer that. Or even where to start answering it. Acutally 10:17
is this the only situation where the parent or grandparent "op" needs to know something from one of its children? 10:18
10:32 brrt left 11:35 zakharyas left 12:03 domidumont joined 12:53 domidumont1 joined 12:56 domidumont left 13:17 lucasb joined, zakharyas joined
timotimo well, i can't quite believe i actually made this work 13:38
now to make it work maybe fast
13:55 brrt joined 14:03 brrt left 14:22 brett-soric joined 14:23 brrt joined 14:30 brrt left
timotimo 736.15user 3.87system 4:51.73elapsed 253%CPU (0avgtext+0avgdata 1190144maxresident)k 14:51
well, that's surely about 2.5x faster than 1x speed 14:52
lizmat timotimo: and what is now faster ? 14:57
timotimo oh, you know, just some trash 14:58
this code will have to be torn to pieces and reassembled into something more usable before it can go into the Moar Heapanalyzer
it's for reading the heap snapshot format that moar will spit out in the future
lizmat aaahhhh more and faster introspection ! 14:59
timotimo well, maybe 15:00
at least the files are now much smaller
er, at least i think they are 15:01
15:10 brett-soric left 15:42 patrickb left 15:47 domidumont joined 15:50 domidumont1 left 16:11 lizmat left 16:46 lucasb left 17:35 brrt joined 17:36 zakharyas left 18:08 patrickb joined
brrt nwc10: Not exactly, there's also operand size 18:09
that's not exactly relevant to flag operators, so..... 18:11
I smell the potential for reusing a field
(you're not *really* a C programmer until you've used a field in multiple ways depending on implicit context) 18:21
TimToady hides in pride^Wshame 18:38
18:43 domidumont left 19:13 lizmat joined 19:14 zakharyas joined 19:16 zakharyas1 joined 19:18 zakharyas left 19:22 brrt left 19:28 brrt joined 20:24 sena_kun left 20:35 brrt left, brrt joined 20:48 zakharyas1 left
Geth MoarVM: patzim++ created pull request #1131:
Build with spaces in path
21:58
patrickb ^- Not for merge before the release! 22:10
AlexDaniel samcv: speaking of which, how is it going? :) 22:11
MasterDuke didn't github recently announce the concept of 'draft PRs'?
Kaiepi yes 22:43
i've been using them
patrickb I found the respective button. Good to know for next time! 22:48
22:50 patrickb left
Kaiepi they're great for wip pullreqs 23:26
23:42 brrt left