dalek arVM: 8620dbf | timotimo++ | src/spesh/optimize.c:
optimize_can_op is fixed and fully enabled now
 00:01
00:33 lizmat joined 01:21 pyrimidine joined 06:07 FROGGS joined 06:55 zakharyas joined 08:10 pyrimidine joined 08:14 moritz joined 08:31 Ven joined 09:08 brrt joined
brrt \o 09:11
FROGGS hi brrt 09:12
nwc10 o/
brrt hi FROGGS :-)
and nwc10 09:13
masak hi brrt 09:30
jnthn o/ brrt
dynasm hacking today? :)
brrt yes, trying at least
i think i know how to do the hard case too 09:31
masak keep us posted! many of us are curious to hear how it's going :) 09:32
moritz seconds that 09:33
brrt i will do that, yes 09:35
masak re-reads news.perlfoundation.org/2015/04/per...ation.html
brrt do you want a short update on the IRC channel or a longer update on my blog :-) 09:38
long story very short, i need to know a lot more about x86 instruction encoding than i had expected 09:44
masak both :) 09:45
nwc10 and a pony!
masak but do the one(s) that don't take too much time from being productive :) 09:46
FROGGS pi@raspberrypi ~/dev $ git clone github.com/MoarVM/MoarVM.git # \o/
brrt \o/ 09:49
well, blogging isnt unproductive, its documentation
:-P
bbiab
10:35 brrt joined 10:43 rudi_s joined, zakharyas joined 10:46 lizmat_ joined
masak blogging isn't documentation -- but I guess it's a good first step. 10:46
10:47 dalek joined
brrt yeah, you're right enough :-) 10:48
arnsholt It's a first step, I suspect 12:07
brrt nah, the first steps are my notebook scriblings] 12:08
arnsholt Troo, troo 12:09
brrt i have an unrelated puzzle to solve, by the way 12:10
or rather, a dillema
i need to read a lot of papers 12:11
reading papers on a computer screen is annoying
printing papers is not very good for the environment 12:12
buying a tablet to read papers on is also not very good of the environment
jnthn Printing on paper is still better for than the environment that producing a tablet :P
*than
brrt is the environmental cost of printing papers ever going to outrun the cost of making that tablet
yes, that's what i'm guessing too
arnsholt I've been wanting to write some slightly more substantial documentation on how to create a language with NQP, based on my experiences with Snake. More or less mal a propos
jnthn mal a propos = bad to propose ? :) 12:13
brrt arnsholt: i know for a fact people are interested in that
arnsholt And reading on paper is still superior, IMO
brrt i think 'poorly suited to topic', but i've never heard of it
arnsholt jnthn: A propos, but a bit of a spurious association. That's how I use it, anyways =) 12:14
brrt i cite: " Thus, a good compiler for a modern superscalar machine is an artful blend of theory, of practical knowledge, of engineering, and of experience" 12:17
arnsholt brrt: Anyways, on the topic of reading papers, I'm 100% in favour of printing. I've been doing it shamelessly for the last four years
brrt :-)
it just feels wasteful, i guess 12:18
arnsholt Yeah, I agree. It's just that reading on a computer is extremely annoying, if you want to pay proper attention
For more superficial readings, it's not that big of a deal. But for really dense stuff (like academic papers), you really need to work much harder 12:19
masak arnsholt: I find it depends very much on the type of screen. 12:20
arnsholt: I read a fair bit on my iPad these days, using the Kindle app. 12:21
arnsholt Oh, neat!
I don't have a tablet, so I haven't tried that
masak most of what I've learned about algebraic topology, I've learned on that screen :>
arnsholt I do have a Kindle, which is really nice for books, but not so great for PDFs
brrt i don't have a tablet and would buy one purely for the purpose of reading. i can't justify that on those grounds 12:22
tadzik *wouldn't
?
brrt i meant: if i would buy one, it'd be solely for the purpose of reading
ironically, that means that if i'd become convinced of it's entertainment value then that would change the equation 12:23
tadzik ah
timotimo brrt: i think it'd be interesting to have a document somewhere that gives a rough step-by-step guide on how to port the moarvm jit to more architectures, perhaps using armel as an example? :) 13:40
brrt hmm
yes
timotimo if i vow to port the moarvm jit to arm, maybe TPF will sponsor a pyra for me :D
brrt it's not a bad idea 13:41
but
dynasm for ARM doesn't have register addressing yet, at all
timotimo at all! 13:42
brrt which means the expression JIT wouldn't work for ARM
that means additional complexity if you'd start on it before the expression JIT was finalized
... although, of course, that's not really what you mean
it's a good idea, yes 13:43
nwc10 what does a dual core Cortex A15 get you that a quad core Cortex A7 doesn't?
timotimo well, you're about to build register addressing for x86; i bet a guide (more or less?) could fall out of that work :)
brrt hah
well....
timotimo nwc10: well 4x7 is a tiny bit less than 2x15
brrt i'll blog about it, how about that
:-) 13:44
there are a few more difficulties i foresee, though 13:48
timotimo nwc10: is that the difference between a raspi2 and the pyra?
brrt basically, nearly all of ARM still uses 32 bit registers, and we use 64 bit registers
timotimo oh, i hadn't realized that
nwc10 timotimo: not the only one
brrt 64 bit values
i mean
timotimo nwc10: well, of course; the pyra is a portable device with keyboard, screen and battery 13:49
nwc10 but it's the most obvious one. In that, is there a proposed cost yet for a pyra?
timotimo i don't quite recall
i expect "expensive*" 13:50
(*when compared to other handheld devices, like a nintendo 3ds, or a smart phone)
brrt (we use 64 values, ARMv7 is 32 bit). that can be worked arround of course, but a larger problem we'd have is that we're being generally sloppy in the current JIT with the distinction
whats more, we generally use large swaths of custom assembly for every block, and all of that would have to be ported 13:51
timotimo of course
brrt if you'd do it after the expression compiler had been put into place, things should be simpler on one hand; you'd just need to define a large enough tileset 13:52
if you'd do it today, your larger challenges would be dealing with ABI (c-calls)
in general, all the architecture specific bits are contained in emit_x64.dasc ; so it's not like all of the graph stuff would have to be rewritten 13:53
that said, i'm not even 100% sure on what the expression IR will be like 13:54
timotimo mhm
brrt it'd be a quite significant challenge to take up in exchange for a pyra computer 13:55
timotimo hmm 13:56
brrt i would add: because /me didn't take portability into sufficient account during the development of the x64 jit 14:00
timotimo i thought having emit_*.dasc would be a good portability "tool" 14:01
jnthn We'd be no better off without it :)
timotimo :) 14:02
i rebased merge_facts_at_phi and ran a spectest, it's all clean
i wonder if i should merge it before it gets forgotten again :)
FROGGS Stage parse : 1407.825 Stage syntaxcheck: 0.042 Stage ast : 0.017 Stage optimize : 274.049 Stage mast : Killed 14:06
Makefile:417: recipe for target 'CORE.setting.moarvm' failed
make: *** [CORE.setting.moarvm] Error 137
:o(
timotimo uh oh
FROGGS what can I do? 14:11
timotimo this is on the raspberrypi?
FROGGS (this happens on the raspberry I own since a few hours)
aye
timotimo ah
i have no idea :\
brrt (aaargh bad news :-( 14:18
)
timotimo uh oh 14:19
brrt ... i need a different strategy
i had expected i could use the marking functionality of dynasm to mark the REX byte
so that i can OR in the right flags at encoding time
however, that won't work because the MARK is also used to mark the ModR/M byte 14:20
in fact, just before the REX byte
eh, the VREG action
on the other hand 14:21
waitaminute
i think i can safely move the mark *after* the vreg
ah, no, not really so easily 14:22
hmmm 14:26
ok, puzzling continues 14:27
hmmpf 14:41
i'm afk for the night
FROGGS :S
brrt no success yet
:-(
sorry kids... i'll figure it out sooner or later :-) 14:42
FROGGS :o)
timotimo i'm expecting that :)
brrt there is always a solution
what there is not always is a nice solution
but always a solution :-)
14:59 JimmyZ_ joined 15:38 FROGGS joined 16:22 synbot6 joined 16:32 vendethiel joined 17:05 vendethiel joined 17:06 colomon joined 17:55 vendethiel joined 18:03 colomon joined 18:09 mj41 joined 18:24 vendethiel joined 18:30 JimmyZ_ joined 18:48 vendethiel joined
hoelzro I've noticed when running Rakudo programs that ps aux shows the gnarly moar command line invocation; is there any desire to have it show the perl6 command line instead? 19:08
jnthn Some, but not enough to make it happen :) 19:18
(yet) :) 19:19
hoelzro =)
it seems that libuv only exposes a binding to prctl, which changes /proc/$PID/name, which ps (on Linux) doesn't use =( 20:04
nwc10 if you want to see what Perl 5 does (and how many different approaches might work) look in mg.c 20:06
search for LOCK_DOLLARZERO_MUTEX
prctl(PR_SET_NAME, ...) might be the most simple to (also) implement 20:07
oh, wait, you just said that
so, sigh, sadly, looks like what's needed is to overwrite argv[0] 20:08
20:17 colomon joined
hoelzro yup =( 20:20
which I'm willing to bet is in an RO segment on some OSen
nwc10 not on any that Perl 5 runs regression tests on. 20:23
hoelzro ok, that gives me hope =) 20:25
jnthn packs up his main dev machine for it's journey to $new-home, and hopes it'll make it in one piece. 20:51
*its
jnthn will have to survive on half the cores for the next days... 20:52
dalek arVM/wip-mvmarray-refactor: f60e50f | jnthn++ | src/ (7 files):
[NOT FOR MERGE] WIP on MVMArray refactor.
 20:57
lizmat jnthn: safe journeys! 20:58
jnthn lizmat: I'm not journeying for another few days yet :) 21:00
Just shipping a bunch of stuff tomorrow :) 21:01
lizmat ah, shipping... let me *not* tell our story of shipping stuff recently until it has safely arrived :-) 21:04
*yours
21:11 brrt joined
jnthn :-) 21:12
jnthn hopes to not have any stories to tell :)
21:14 dalek joined
jnthn Having just seen the back of this machine for the first time since I got it ~1.5 years ago...I think I can say a can of compressed air will be one of the first purchases when I get it over to Praha :) 21:14
brrt (what kind of machine uses compressed air? :-o) 21:15
or, compressed air as a cleaning tool
oh, i've come to ask for advice
lizmat jnthn: you should see it if you have cats :-)
brrt not sure if advice is the right word, but
lizmat is in 2 minds: do I say "don't do that" or "go for it!" ? 21:16
brrt i had planned on using the generic marking facility of dynasm to signify the REX byte (the one that has to be extended in order to address the upper GPRs)
lizmat
.oO( can't give a sensible answer to that one )
 21:17
brrt however, that won't work; the ModR/M encoding machinery relies on the same marking facility, and sits between the rex byte and the vreg action byte (the one that instructs dynasm to encode a dynamic register) 21:18
so i'd expect to modify my REX byte and would in fact modify the ModR/M byte
less than awesome
the easiest way out of this would be to add another way of specifically marking the REX bytes 21:19
it'd be called MARK_REX of MREX or something like that
in general, i'm more in favor of *using* functionality rather than creating it. but i don't think i have much choice now 21:20
do you think this is a sensible way forward? 21:21
(i have one more issue left,though, to figure out exactly in which bit of the rex byte the extension bit goes. but i can figure that one out, i think, or change dynasm to provide the information at runtime)
(am i making sense at all) 21:22
the alternative would be searching the byte, i guess? 21:24
jnthn Well, if you've a state machine that doesn't have the state you need... :) 21:25
brrt i suppose that's the state i find myself in, yes :-) 21:26
hey, what's going on with the mvmarray-refactor thingy 21:29
:-)
jnthn It's wise to look for existing things to re-use, but going too nuts on that can end up in a worse place...
brrt: That's a pile of code that was sat on a machine that's about to spend (hopefully just) several days on the road, and I wanted it to hand in case I decided to hack on it in the next days :) 21:30
but it doesn't even build
So I figured I'd flag it prominently to stop folks wasting much time reviewing it :) 21:31
(or trying to build it, 'cus it doesn't build either)
brrt right :-) i didn't know that it was a goal to change mvmarray
good news, for once 21:40
near as i can tell dynasm already differentiates between the kind of things it puts into SIB/ModRM bytes 21:41
(both are involved with addressing)
i think it does it for internal checking purposes
but for me it means i can use that to decide which bit to set in the REX byte
23:11 vendethiel joined 23:59 vendethiel 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!