00:57 btyler joined 01:13 FROGGS_ joined 01:38 woosley joined 02:50 daxim joined
japhb brrt: I've actually been begging for a way to reinterpret 32 or 64 bits between integer and floating point forms (as a fast way of converting floats to and from network-serialized form), so if you get that as a side effect, I won't complain. :-) 02:58
Also, on Intel processors (since the 8087 days), the floating point registers are 80 bits wide ("long double" form) to prevent (or rather, reduce the probability of) certain types of precision losses during extended calculations. 03:02
You *can* store the long doubles to RAM, but generally they're just used internally to a single calculation and then the result stored in 64-bit double form. 03:03
You would need to store the extended form to RAM if you had to spill registers during the middle of a calculation when the programmer was expecting to stay in high-precision form. 03:05
03:16 daxim joined 03:48 benabik joined 05:52 cognominal joined 06:53 FROGGS_ joined 07:03 zakharyas joined
jnthn moarning o- 07:08
nwc10 good *
jnthn eww, what keyboard layout...
nwc10 You're not in Sweden? 07:09
jnthn yeah...it was the Swedish one :)
nwc10 oh, so your keyboard has flipped layout? PEIK, not PEBKAC? 07:10
FROGGS_ moarning oß 07:12
jnthn No, just me not remembering I'm on a machine where they put images on taht default that way
oh joy, my presentation gadget has a flat battery
yay, new batteries. :) 07:14
It may be a good idea to bump NQP_REVISION and MOAR_REVISION, btw 07:17
So we get some testing on latest
Also, if anybould could check Panda builds OK on non-Windows on latest of everything that'd be great.
(I tried it yesterday on almost-HEAD on Windows and modulo a Panda patch we need on Windows, it worked well) 07:18
(Panda patch is backend-independent.)
jnthn is teaching for the day but has evening tuits :)
FROGGS_ \o/ 07:19
I can check panda later
jnthn ok 07:29
teaching &
08:00 krunen joined 09:23 oetiker joined
lizmat am going to bump revisions now, ok? 09:51
revisions bumped 10:12
10:45 jnthn joined 10:52 odc joined 11:27 brrt joined
brrt \o #moarvm 11:27
lizmat brrt o/ 11:36
brrt how's it there? still in france?
lizmat no, back in Echt for now 11:37
brrt really? (ha ha) 11:38
well, how was france, then? :-) 11:39
lizmat apart from the bombing of a bar, nothing much happened while we were away
well, the same more or less
tadzik bombing of a bar? :o
lizmat we've been to the Cite des Sciences many times already
two motorgangs are disputing the territory here 11:40
they've been thrown out of Germany, and are now trying to set up "shop" here
brrt annoying 11:41
lizmat yeah, but as long as they're not gunning each other down with machine guns, it's just that
spurious S17 errors did not seem to have disappeared :-( 12:02
*do
FROGGS_ perhaps somebody needs to fix 'em? 12:11
that is usually what somebody does with errors :o)
lizmat wish I had the know-how to 12:12
not something I can do about it at the rakudo level :-(
brrt what are the s17 crashes about? 12:14
locking, right?
brrt finds concurrency fun 12:15
lizmat afaik, from talking with jnthn, some kind of memory corruption that happens under stress
brrt things we should have something like the go race detector 12:18
nwc10 brrt: have you played with helgrind? Does it acchieve that?
brrt have never, no 12:20
my debug toolbox is basically gdb and since recently, valgind
(and printf, of course :-)) 12:21
13:11 jnap joined 13:23 flaviusb joined
jnthn wonders what nice JIT commits brrt++ will land today :) 13:35
lizmat: Thanks for the bump.
brrt is a bit preoccupied in fact :-)
i was thinking of doing the branching stuff today 13:36
or at least
the labeling-of-basic blocks
lizmat FWIW, spectest CPU usage seems to have gone down from ~1544 to ~1483 13:37
timotimo that could be inline landing? 13:39
13:42 FROGGS_ joined
brrt conditional branches, fwiw, are awkward 13:42
FROGGS_ lizmat: you are right of course # META6.json 13:43
err, ww
moritz are there non-conditional branches?
brrt in that moarvm expects you to put the result of a compare into a register - ok - and then to use the boolean result of said register to jump
and that is all possible
but the 'normal' way to do it is to compare, and then jump directly on basis of the flags register 13:44
that said, its not particularly hard to do it as i described, just very roundabout
jnthn brrt: Sounds like a make-it-work-now, peephole-it-later situation 13:47
timotimo agreed
brrt agreed as well
but awkward :-) 13:48
moritz - a nonconditional branch is a goto :-)
otherwise we'd have to call them goto and branch, now we just call them branch
on the otherhand, qualifiying with '(un)conditional' isn't exactly succinct terminology either 13:49
FROGGS_ what's a pee phole? 13:51
nwc10 a "peep hole" with 2 characters transposed? 13:52
FROGGS_ meh
timotimo it's a type of optimizer that looks at a few opcodes in isolation 13:53
it looks at the opcode stream "through a little peep hole" so to speak
comparable to a "sliding window"
jnthn a...pee phole? :P 13:54
None of the mental images are good :P 13:55
timotimo a pee pole sounds even less good 13:56
brrt wishes people had picked another name
lizmat Tea See Pee, I Pee
what can I say, the level is rising :-)
timotimo my initials are TCP :3
brrt its actually called a peephole optimizer - the optimizer runs over the bytecode in a small 'window', and tries to find things to optimize
and most of the usable algorithms have to do multiple passes 13:57
13:58 btyler joined
timotimo yeah, single-pass optimization is kinda hard 13:58
brrt and its not actually very easy to use it with the current version of the jit graph because it treats (for now) things like compare will be handled by primitives (i.e., not looked at on graph construction level) 13:59
i.e. 'jit graph should be a real graph!' 'i know but i'll need register selection' - that discussion, again :-) 14:00
timotimo well, it would be easy to remember the "origin" instruction for each register/version and traverse that like a linked list when we find a conditional branch op 14:01
brrt yes, certainly
def-use analysis, made more easy by the SSA form
timotimo aye
brrt block labeling is first, though 14:02
timotimo jnthn: what exactly forces the attribute access in cursors to be pessimal? that we access them late-bound by name? 14:03
14:05 oetiker joined
jnthn no, that we use ::?CLASS 14:06
timotimo mhm 14:08
is that constant-per-callsite per chance?
jnthn constant per invocant type 14:16
decommutebeer & 15:00
lizmat beer on the train! 15:03
lizmat recalls being on the commuter train to Antwerp
everybody ODing on coffee in the morning 15:04
and ODing on beer in the evening on the way home :-)
.oO( happy hour for sure )
brrt lizmat - from roosendaal? 15:39
lizmat yup
in the blue "hondekop"
brrt has been on the roosendaal train quite a few times himself 15:40
but not on a blue train, actually
red trains ride there nowadays
lizmat yeah :-( 15:42
brrt (slowly) 15:45
16:25 brrt joined 16:28 brrt left 17:03 jnap joined 17:04 flaviusb left
jnthn No, it wsa beer at the pub by the station, before the train 17:25
17:28 jnap joined
lizmat ah, using RPN then :-) 17:29
jnthn Reverse Polish Notation? :)
oh :)
lizmat hehe 17:30
not &beerdecummute but decommutebeer&
18:02 vendethiel joined
dalek arVM/moar-jit: bd6ecce | (Bart Wiegmans)++ | / (7 files):
Add comparison operators before adding branching
 18:50
18:50 brrt joined
brrt is becoming fond of asm 18:53
brrt chuckles at the following comment: github.com/LuaDist/luajit/blob/mas...dasc#L6243 19:02
rurban_ brrt: do you really need to add pseudo frames? They are only used for exceptions 19:04
brrt pseudo frames?
thats not my code, btw :-)
rurban_ yeah, just to walk up the stack frame to find someone who can catch the exception 19:05
sure. I do not support exceptions with native stack frames. way too fragile
brrt i... don't think that i do?
rurban_ I hope not.
brrt stack management is fragile per se :-) 19:06
rurban_ You can try to support dwarf2/dwarf3/llvm vs gcc, elf vs mach vs windows, mingw dwarf2 vs sjlj and many more
brrt yes... i suppose i can 19:07
rurban_ I hope not :)
brrt however, i'm already more than glad if i can support two different x64 ABI's :-D
rurban_ If you really need it, better call the assembler manually to produce those frames 19:08
brrt hmm but dynasm runs at runtime
rurban_ win64 vs amd64 is easy, just 2 different registers 19:09
brrt win64 also has more callee-save register (rsi and rdi)
and fewer register arguments
but i agree
its doable
rurban_ yeah, my perl5 Jit compiles some crazy frames to .c and then .o and then gets the dwarf at run-time. just for debugging, gdb support, to get the symbol names. 19:10
brrt hmmm
rurban_ newer gdb's have better jit support already
brrt the moar-jit project works at a bit of a lower level, though
ultimately, gdb support would be good, i agree 19:11
rurban_ you might need it later, when you want to step through it. single-step is a bit troubling
brrt then again, not as good - imho - as the generation of Very Fast Code :-)
i use bytecode dumps that i dissassemble offline 19:12
rurban_ so with these dwarf frames you can add the lines and even variable names and types
brrt or
i trap MVM_enter_jit in gdb and disassemble on-line
that is pretty neat
brrt should have that too :-)
although i can promise it won't be a priority anytime soon :-) 19:13
(and of course, i know the bytecode generation routines well enough to recoginse seperate fragments by hand, but that won't be true of anyone else) 19:14
jnthn The easy way to deal with exceptions initially is just deopt.
rurban_ I only implemented it when I could't properly debug mine anymore. And I'll probably such a think to the new (=old) parrot jit also.
brrt jnthn, i think / but i'm not sure - rurban_ means stack-unwinding exceptions, and since we don't have a deep c stack, walking isn't a problem, either 19:18
i'll have the interpreter handle the frame walking / handler selection part 19:19
jnthn *nod*
Yeah, well, we basically never recurse on the C stack even if the code we're running does.
If the handler is in a caller, it's thus really easy to drop back to the interp. The only tricky one is when the handler is in the current frame, and you kinda need a deopt record to know where to fall back to, 'cus it can't just be inferred from the return addr or so. 19:21
Control exceptions in the same frame will want to become gotos at some point, I imagine.
But maybe that wants doing in spesh rather than the JIT per se.
brrt they can be equivalent to gotos
goto's don't hurt me :-) 19:22
jnthn Well, we only need to do the full-blown thing if there's a CONTROL or so somewhere, but that's the uncommon case. :)
brrt i suppose so. i'm nowhere near exceptions now, though 19:25
jnthn aye :) 19:26
19:55 jnap joined
dalek arVM: 462402b | jnthn++ | src/spesh/args.c:
Missing NULL check in arg guard handling.

Fixes a SEGV reported by Mouq++.		 20:25
lizmat enough reason to bump? 20:26
jnthn: ^^^ 20:29
jnthn lizmat: Well, figure I'll test Panda builds fine on this latest just in case I need to fix something there 20:30
I know there was a SEGV in that earlier on.
But I didn't reproduce it the other day
Gonna check it out now, anyways...
lizmat jnthn++ 20:31
jnthn Oh, do you have a Panda commit bit?
lizmat no sure 20:32
I might need one soon :-) 20:33
jnthn I asked on #perl6
Just a patch I have that wants applying
lizmat nope, don't have a commit bit 20:35
guess I should ask tadzik for one 20:36
jnthn Looks like (with that Windows patch) Panda builds fine here. 20:51
So yeah, can bump.
lizmat ok, will do 20:55
21:41 donaldh joined 22:07 brrt left

Powered by Cro and the Raku® Programming Language.

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

Thank you!