|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 20 May 2018. |
|||
|
00:00
lizmat joined
01:56
shareable6 joined
01:58
ilbot3 joined
|
|||
| moderator | github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today | ||
|
06:21
robertle joined
06:33
AlexDaniel joined
07:21
domidumont joined
07:28
domidumont joined
09:12
AlexDani` joined
09:56
lizmat joined
10:32
AlexDani` joined
10:43
brrt joined
|
|||
| brrt | good * | 10:43 | |
|
10:53
shareable6 joined
|
|||
| jnthn | o/ brrt | 10:57 | |
|
11:00
Kaiepi joined
|
|||
| brrt | \\o jnthn | 11:27 | |
| so, do you care to hear the story of the label miscompile | |||
| the ultimate question is 'do we go for the pragmatic, correct solution that is maybe a couple bytes bigger, or do we solve the problem completely' | 11:28 | ||
| i figured out what it is, well, for the first 90% or so | |||
| so... the reason i'm being so dogged about this, aside from label miscompiles being really scare, is that I think that not only can we eliminate the jit_entry_label assignment, I think we can eliminate the throwish and invokish prologue and epilogue | 11:47 | ||
| roughly said; if we have a fixed pointer to the return-address on the stack, surely we can update this pointer as well, and just assign it to the frame exit whenever we leave the frame (by invocation, as well as by unwinding) | 11:48 | ||
| and similarily with within-frame exception capture | |||
| jnthn | Sorry, was off at lunch :) | 12:01 | |
| brrt | well, that's necessary as well | 12:05 | |
| jnthn | Hm, if you understand the problem, and we'll want to solve it completely at some point, maybe it's worth doing it sooner rather than later. | 12:13 | |
| Interesting idea about the return address. Hmm. | |||
| That'd seem like a big saving | |||
| brrt | yeah.... i'm hoping i can make it work | 12:16 | |
| one of my annoyances is that 'special return' handlers can throw | |||
| we can also ignore the problem and hack dynasm to never decrease label sizes | 12:17 | ||
| i mean, that simplifies a *bunch* of things. | 12:18 | ||
| then again... | 12:21 | ||
| ok, here's what i'll actually do. in dasm_put, i'll aggressively increase the offset. in dasm_link, i'll switch to decrementing the offset in the invalid conditions | 12:25 | ||
| i.e. dasm_put can only increase the offset, dasm_link can only decrease it | |||
| that way, I can never end up believing in the first pass that I can put it in a single byte, and then overflow | |||
| i notice that the original code also holds that constraint | 12:26 | ||
| so lets' try that out | 12:30 | ||
|
12:55
Kaiepi joined
12:56
Kaiepi joined
12:58
Zoffix joined
|
|||
| Geth | MoarVM/jit-stack-walker: 15 commits pushed by (Bart Wiegmans)++ review: github.com/MoarVM/MoarVM/compare/0...120690fcb7 |
14:24 | |
| Zoffix | .ask brrt did you ever write down the guide for implementing new ops? I'm taking you up on your call for adding ops that could be faster than HLL code. I need a rational-reducing op | 15:57 | |
| yoleaux | Zoffix: I'll pass your message to brrt. | ||
|
16:24
shareable6 joined
|
|||
| timotimo | hm, difficult, we only have ops that have a single write register so far | 16:32 | |
| i suppose with a rational-reducing op you'll really want to have two result values? | |||
| it could require the use of lexicalref i guess | |||
| nativeref of any kind, really | |||
| hm, if you make it an extop inside rakudo, we can probably make more assumptions, or just immediately use getattr/bindattr in the implementation | 16:33 | ||
| Zoffix | timotimo: ideally single result, Rat, FatRat, or Num object | 16:35 | |
| Zoffix goes for a nap | |||
| timotimo | may be a bit fiddly; you'd have to pass in the types Rat, FatRat, and Num somehow | 16:38 | |
| TimToady | or some descriptor containing those maybe | 16:56 | |
| TimToady has been thinking about how to pass the current Match object into the nfa so it can cache fates there... | 16:57 | ||
| timotimo | right, a hash would do | ||
|
17:19
domidumont joined
17:47
Ven`` joined
17:52
Ven` joined
|
|||
| japhb | brrt: (backlogging from the 18th): Yes, the GPU is a completely different architecture. It also satisfies *both* of my requirements: 1) it was LOTS faster than anything existing when it came out, and 2) it gained massive non-graphics popularity exactly when it became a compile target for C/C++ code, initially in the form of CUDA/OpenCL, and eventually as regular old C++. :-) | 18:05 | |
|
18:18
shareable6 joined
18:55
AlexDaniel joined
18:59
Ven`` joined
|
|||
| lizmat | samcv: is something blocking a MoarVM release ? | 19:06 | |
| Zoffix | timotimo: why fiddly? nqp::div_In() takes a Num and an Int type objects. I figured nqp::ratreduce() would be the same nqp::ratreduce(nu, de, Rat, FatRat, Num) | 19:51 | |
|
20:01
Kaiepi joined
|
|||
| Zoffix | Guess it kinda gets more complicated if ZeroDenominator role lands. But we could start with nqp::ratreduce_I(nu, de, Int) that returns and nqp::list() with numerator/denominator as elements, no? | 20:48 | |
| s/and/a/; | |||
| timotimo | that seems possible, yeah | 20:52 | |
|
22:51
nebuchadnezzar joined
|
|||
| samcv | lizmat: nothing i know of no | 23:16 | |
| Zoffix | Release! 🙂 Release! 🙃 Release! 🤗 Release! 😊 Release! 🏎 | 23:48 | |
| timotimo | since i came back to xfce4 from plasma i can now see many emoji in my terminals | ||
| MasterDuke | isn't that just a function of the font you choose? | 23:50 | |