00:12 ggoebel joined 01:28 IRCFrEAK joined, IRCFrEAK left 02:48 ilbot3 joined 03:16 BenGoldberg joined 04:35 madgoat joined, madgoat left 07:31 brrt joined
brrt good *, #moarvm 07:32
nwc10 good *, brrt
brrt ohai nwc10 07:33
i was just trying to figure out how to do the special tiles thing…..
nwc10 "with a hammer" 07:34
or, "bigger hammer"
brrt well, everything looks like a nail anyway
nwc10 given that it's tiles, maybe that's *not* the right tool
brrt i hadn't taken the complexity of dealing with the 'synthetic' tiles properl into account yet 07:36
08:17 brrt joined 08:23 zakharyas joined
brrt so another thing i thought of; a 'node' of the expr jit is now necessarily 64 bits wide in order to store pointers; but that is in a way a ridiculous requirements while virtually all trees I can think of can be stored in 16 bits, and certainly all in 32 bits 09:04
but if I add some syntax to detect pointer references in the expression tree, I could compile code to store them in a list (i.e. use an extra layer of indirection to store the, relatively rare, pointers) 09:05
an advantage of that is that it could go some way to make storage-and-linking work, i.e. those pointers could be stored in the data section and matched with labels and addresses 09:07
i don't really see a disadvantage to that….
lizmat brrt: fwiw, it smells like a premature optimization to me 09:32
brrt possibly, yes 09:38
(what, me, overingieer?)
jnthn morning, #moarvm 09:43
brrt moarning jnthn 09:45
that said this bit has been on my mind for a *long* time now, so i'm just going to record a plan for it, and do it later :-) 09:48
more to the point, this has some beneficial side-effects as well, since 'real' large 64 bit values typically want to be handled differently from 32 bit constants, at least in x86 09:55
i.e. loading a 64 bit const requires a movabs (which requires a register), or a load-from-data-section; which means that it doesn't work inline like a 32 bit constant does 09:56
so ultimately, from the tile perspective, this could be a large simplification, since I could just make tiles like ADD not support loading 64 bit constants
Geth MoarVM/even-moar-jit: 4494d851d7 | (Bart Wiegmans)++ | 2 files
Find 'special' tiles and stub handling them

Some of the infrastructure (notably, a map of register -> live range) to actually compile CALL and ARGLIST is not yet available. But now we can at least find these tiles.
That said, it might be nice to roll ARGLIST and CALL into a single tile so we can ensure that loading the argument to CALL (sometimes a dynamic pointer) will not conflict with call arguments set up by ARGLIST.		 10:03
MoarVM/even-moar-jit: 3374d2844f | (Bart Wiegmans)++ | docs/jit/plan.org
Investigate large constants

Large (64 bit) constants currently force a excessive expression node size, and they typically need distinct handling from 'regular' constants, esp. pointers, which we would like to have in a table for linking, and for binary operators, in which directly using a 64 bit constant is not directly supported on x86 while a 32 bit constant is. So it would be interesting to split the large constants from the small ones.
brrt (i did not decide to use the queue, after all, although elegant, a cursor would do just as well)
11:23 pyrimidine joined 12:15 sivoais joined
dogbert11 jnthn: sorry to be a nuisance :) but should I do anything else wrt lizmat's bug. Do you have all the info you need (or a hint if you would like me and/or timotimo to fix it)? 12:27
jnthn dogbert11: Mostly now I just need time to look more closely at what you've found :-) 12:30
dogbert11 jnthn: ok, let me now if you want me to try something else in case you need more info 12:32
jnthn Will do; thanks! :)
dogbert11 will check out the RT SEGV list in the meantime
lizmat dogbert11: which bug are you referring to? 12:35
something I did, or something I reported ?
dogbert11 lizmat the latter your harness6 troubles 12:36
lizmat aaaahhh :-) ok *phew* :-)
dogbert11 do you run it with a high number of TEST_JOBS? 12:37
lizmat 8 12:38
not sure that's high, it's the number of virtual cores my MBP has
dogbert11 cool, so you have a 4 core CPU with hyperthreading then 12:44
12:48 MasterDuke joined 13:02 zakharyas joined
TimToady I regularly run with 6, and still get the occasional flakeouts 14:48
(on a 4-core)
brrt yeah, same here 14:51
but mostly on linux, though
TimToady same 14:52
dogbert11 TimToady, brrt are you both running with harness6? 15:15
brrt well, i'm running whatevers the default, really 15:16
dogbert11 'make spectest' defaults to harness5 if I'm not mistaken. What kind of flakeouts are we talking about here? 15:17
brrt well, tbh, i don't have it available, but last I knew IO::Async::Sockets test could still lock up 15:21
TimToady t/spec/S11-modules/require.rakudo.moar (Wstat: 65280 Tests: 11 Failed: 1) Failed test: 11 Non-zero exit status: 255 Parse errors: Bad plan. You planned 27 tests but ran 11. 15:22
but then run by hand it worked fine
that's just with default harness
dogbert11 hmm 15:44
16:05 brrt joined 17:46 BenGoldberg joined 18:17 dogbert17 joined 18:56 pyrimidine joined
BenGoldberg Can someone give me some advice? I want to compile moarvm, and I'm on windows. 21:50
jnthn I tend to build it with the MS VC++ toolchain
BenGoldberg was hoping he wouldn't have to learn visual studio ....
jnthn You don't
Just need the command line tools 21:51
BenGoldberg That sounds much less sucky ;)
What would you recommend I install?
Any specific version which is easier to put in and use? 21:52
jnthn On www.visualstudio.com/downloads/ I think if you find "Microsoft Visual C++ Build Tools " (near the bottom) that should get you just the command line tools
BenGoldberg "Microsoft Visual C++ Build Tools 2015 Update 3 21:54
" ?
jnthn Yeah 21:55
BenGoldberg I also see "Build Tools for Visual Studio 2017 RC" 21:56
The desc says "These Build Tools allow you to build native and managed MSBuild-based applications without requiring the Visual Studio IDE"
jnthn Think that's just a newer version 21:58
I'd stick with the older one
Last time I used an RC of something from MS it was a screw-up
BenGoldberg And here's the reason why I want to build moar -- I want a perl6 plugin for my favorite irc client, hexchat, and, since there isn't one, I'm writing it. 21:59
I've got the start of a plugin here: gist.github.com/BenGoldberg1/de452...9805528115 22:01
jnthn Cool :) 22:04
gist.github.com/BenGoldberg1/de452...erl6-c-L91 22:12
You'll get a compile error in MSVC on at least this line, fwiw
(It wants all decls at the top of the function)
(or block)
BenGoldberg Right, C not C++ :)
jnthn Well, C99 lets you do that 22:14
But Microsoft decided they'd bet the whole house on C++
BenGoldberg tries to remember where he copied this code from -- who the f sticks pointers to local variables into a global object. 22:15
jnthn Inline::Perl6, maybe? :) 22:18
BenGoldberg Yeah, Perl6.xs, I'm looking at you. 22:19
Are those pointers not needed after toplevel_initial_invoke? 22:20
Also, what's with that start_frame? It's never used anywhere.
jnthn heh, indeed, so it can go away 22:21
Which local vars are you worrying about? 22:22
Oh, I see
No, they won't be used after toplevel_initial_invoke returns 22:23
BenGoldberg Ok, I was worried.
Also I see that 'MVMCompUnit *cu' is only used inside of initialize, but it's declared as a global. 22:24
jnthn That's a tad curious also 22:25
Should probably take this and hide some of the structure pokery behind a proper API
BenGoldberg Since hexchat is a gui irc client, it doesn't have a proper stdout/stderr. Is simply assigning my own object (with .print and .say methods) to $*OUT and $*ERR sufficient to make sure all errors and prints get sent to the screen? 22:33
I'm worried about low level C code doing a printf :) 22:34
moritz that wouldn't land in $*OUT or $*ERR
but shouldn't happen in normal Perl 6 code either 22:35
BenGoldberg It would land in the bitbucket.
jnthn Sleep time for me; 'night 22:41
BenGoldberg G'night, then 22:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!