01:48 ilbot3 joined
dalek arVM: 45863d1 | jnthn++ | src/core/exceptions.h:
Register some further control exceptions.

Related to upcoming async features in Perl 6.		 02:30
arVM: ec051f5 | jnthn++ | lib/MAST/Nodes.nqp:
Add new control exceptions to MAST::Nodes.
03:20 ingy joined 07:18 zakharyas joined 08:36 Ven joined 09:13 rarara joined 09:28 rurban_ joined 11:38 FROGGS_ joined 12:26 Ven joined 13:11 brrt joined 13:15 brrt joined 13:26 Ven joined
brrt i just had the luminous (i think, and hope) idea of having a 'conditional block' flag 13:41
into the register allocator
that signifies that the values and blocks allocated then are used conditionally, and hence should be cleared together 13:42
you know what i mean?
timotimo i think i understand 13:43
clearing doesn't mean actively nulling, right? just marking as re-usable?
brrt for conditional blocks, its complicated 13:51
do you want the long version?
timotimo only if it helps you advance 13:52
brrt (but yes, invalidation doesn't mean you erase their contents, just mark them as safe to use)
timotimo otherwise i'll likely understand once i get into the finished implementation
brrt basically, registers can be in one of three states
free, allocated, and used
free means there is no node that refers to them 13:53
timotimo mhm
brrt allocated means that they are currently inhabitated (as it were) by the value of a node
i.e. the node is held there
actually, hmmm
no, allocated means that it's safe for the allocator to use it 13:54
hmm
no, my first instinct was correct, but it means i'll need to make adjustments
anyway, used means the register is currently in use by an operation, and cannot be spilled 13:56
timotimo mhm 13:57
brrt an allocated register can be spilled and made free, a used register cannot
must be explicitly released for that to happen
timotimo right 13:58
brrt now i was thinking, what if upon entering a conditional block, i marked it so, so that registers allocated and values calculated within that block can be made 'invisible' upon leaving the block
i.e. have a new 'conditional block' stack, or something like that 13:59
hmm
this thing is becoming mighty complicated already...
timotimo right; i don't think it can be helped very much
brrt anyway, and i probably need to up-propagate register usage counts for that to work out 14:00
possibly during the value selection step (the last tiling step)
14:01 synbot6 joined
brrt so that i can also mark a block as possibly invalidating the whole register set (e.g. during calls) 14:01
timotimo right
brrt which sucks, by the way 14:05
join me in the campaign against function calls
timotimo heh 14:06
let's build an x86 meta-interpretor that figures out what registers are used and what registers aren't
and ... other things 14:07
14:08 Ven joined
brrt lol 14:15
no, that's fortunately not necessary :-) 14:16
you know, i had a thought yesterday evening 14:17
in some 10 years or so, installing an AI discriminator / neural network is going to be as easy as installing MySQL is now
isn't that weird? 14:18
timotimo a bit, yeah 14:19
but training would still be a bit of an effort, no?
brrt hmm, probably, but there'll be easy-to-use training wizards, or pre-trained sets 14:21
training, designing and querying a neural network is likely to be a skill as common as relational or object-oriented modelling is today
although, that may take a few more years
people still suck at SQL. but they'll suck at neural nets in mostly the same way, i think 14:22
timotimo possibly 14:23
brrt you know what won't change? the front-end hell :-)
timotimo %)
brrt oh, programmers will talk, and whine, and fight little wars over frameworks and standards and build tools... 14:24
but really? it's still about making things visually appear in a way suitable to our own neural network, trained on fruit picking and predator detection 14:25
14:31 colomon joined
timotimo oh yes 14:42
15:11 tadzik joined
brrt hmmm.... 15:23
can't do nested ALL or ANY i think
that works out really ugly 15:24
15:38 rurban_ joined 16:04 pyrimidi_ joined, pyrimid__ joined 16:16 Ven joined 16:19 brrt joined 16:44 colomon joined
dalek arVM/even-moar-jit: b870a79 | brrt++ | src/jit/compile.c:
Mostly implement branching

Except for register/value invalidation, this mostly implements branching, including short-circuiting for ANY/ALL and nested ANY/ALL.		 16:51
brrt nested ANY/ALL should work now
Ven brrt++ !! 16:57
brrt Ven :-) 16:58
Ven++, even
Ven brrt: I'm pretty clueless about the JIT, but I'd love to understand what this means: github.com/MoarVM/MoarVM/commit/b8...f47d18R297 17:00
brrt alright, i can explain that, should be fun 17:01
you know short-circuit evaluation, right?
if (foo() || bar()) only evaluates bar() if foo() was false
basically, WHEN is a unary conditional block node 17:02
i.e. it's equivalent to if (condition) { block; }
(unlike IF and EITHER which are binary, whereby IF yields a value and EITHER does not) 17:03
anyway, to implement short-circuit evaluation for the OR case (called ANY here because it is variadic, e.g. takes multiple arguments)
what you need to do is jump into the block after foo() is true
so far so clear? 17:04
(and you need to jump beyond the block if you reach the end with bar() being false) 17:06
well, that's kind of the logic that determines these things 17:10
Ven re-reads another time 17:13
brrt :-)
Ven yes, that's clear 17:14
the only part i don't seem to get is the "if/either" being binary
brrt oh, that's just an IR tree design decision
Ven and what does it entails? 17:15
brrt basically, nodes should best have a fixed number of children, to deal with more easily
Ven oh, you mean if has some kind of "tails" node
that's there for the "else" part?
brrt yes, the IF node has two alternatives (the 'true' and 'false' blocks), and WHEN only has a 'true' block 17:16
obviously WHEN cannot yield a value 17:17
Ven alright, I think I got it :)
thanks. brrt++ # jitting my brain
brrt ok great :-)
if you have any more questions, be sure to ask
17:50 Ven joined 18:32 ggoebel joined 19:07 zakharyas joined 20:40 colomon joined 21:33 colomon joined 21:53 TEttinger joined 23:01 danaj 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!