|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 5 July 2013. |
|||
|
01:33
eternaleye joined
01:40
eternaleye joined
01:56
FROGGS_ joined
02:01
eternaleye joined
04:24
benabik joined
04:59
birdwindupbird joined
05:50
ggoebel2 joined
06:39
FROGGS_ joined
09:06
pmichaud_ joined
09:13
diakopter joined
09:15
Tene joined,
itz joined,
patspam joined,
rblackwe joined,
tokuhirom_ joined,
jnthn joined,
chipdude joined,
`patch` joined
09:59
eternaleye joined
10:53
eternaleye joined
11:28
eternaleye joined
11:33
FROGGS joined
11:57
prammer joined
16:07
FROGGS joined
|
|||
| FROGGS | jnthn: do you think there is something I could already do vor MoarVM? | 16:12 | |
| for* | |||
| damn it, I can't type today | 16:13 | ||
| jnthn | You can't type, but you want to hack on a VM??? :P | ||
| FROGGS | :P | ||
| well | |||
| compilers usually tell me about typos :o) | 16:14 | ||
| jnthn | Anyway, yes, there's surely things to do. Are you decent in C? | 16:15 | |
| Though to be honest, talented but indecent in C is fine too... | |||
| FROGGS | well, I know a bit about C and did things in PerlXS | 16:16 | |
| any LHF that is good as a start? | |||
|
16:18
Tene joined
|
|||
| jnthn | FROGGS: Well, NQPLHLL.nqp has various nqp:: things commented out. | 16:18 | |
| Some of those may well be LHF. | 16:19 | ||
| FROGGS | cool, will have a look | 16:21 | |
| jnthn: thanks | 16:22 | ||
| diakopter | FROGGS: also, if you'd like, you could help realize the extops branch | 16:40 | |
| jnthn: <nudge> | 16:41 | ||
|
16:46
colomon joined
|
|||
| FROGGS | diakopter: extops is about p5interop I guess? | 16:54 | |
| diakopter | FROGGS: well, not directly | 17:00 | |
| FROGGS | diakopter: what is it? (in short) | ||
| diakopter | it's about enabling native extensions | ||
| (and adding extension ops to access them) | |||
| in the extops branch see docs/extops.markdown | 17:01 | ||
| FROGGS | okay, will do | 17:02 | |
| diakopter | I expect jnthn to rubberstamp it since it's essentially identical to what we already talked through | ||
| one or two tiny changes/additions that aren't really binding/consequential | |||
| FROGGS | k | ||
|
18:09
ssutch joined
|
|||
| diakopter | ssutch: hi :) | 18:13 | |
| ssutch | hello! | ||
| diakopter | FROGGS: let me know what you think of that | 18:14 | |
| jnthn: ping | |||
| jnthn | diakopter: pong | 18:46 | |
| diakopter | jnthn: just wanted to point out what I added to that markdown that we didnt' talk about before | 18:56 | |
|
19:00
eternaleye joined
19:51
lizmat_ joined
19:54
FROGGS_ joined
19:57
nwc10_ joined
20:06
tadzik joined
|
|||
| diakopter | jnthn: did you want to hear it? | 20:08 | |
| jnthn | diakopter: yes, go ahead, just been writing up $dayjob stuff today in case somebody needs to support what I did while I'm away on vacation :) | 20:11 | |
| Done that now, so can look at your thingy :) | |||
| diakopter | really the only difference was allocating the opcodes | ||
| 0-4095 for built-ins, 4096-32767 for extension ops, the rest for JIT hooks | 20:12 | ||
| seem okay? | |||
| (32768-65535 for JIT hooks) | 20:13 | ||
|
20:15
tadzik1 joined
|
|||
| diakopter | so, 16 banks for built-ins | 20:18 | |
| jnthn | Sorry, got phone call... | 20:32 | |
| diakopter: JIT hooks? | |||
| jnthn reads | 20:33 | ||
| diakopter | jnthn: well, I was just thinking about how to inject JIT calls | 20:34 | |
| jnthn: er, calls into JITted things | |||
| jnthn: I mean, for times that not the entire routine is JITted | 20:35 | ||
| jnthn | Under "#### Representing Extension Op Calls on Disk and in Memory", while we're probably both thinking it, it may be worth making it explicit we expect the table to be dense, not having any holes... | ||
| diakopter | k | 20:36 | |
| jnthn | oh, it's kinda stated in the next section...maybe still good to clarify up front though | ||
| "throw a bytecode validation exception" - again, obvious, but error should contain the name of the op and the signature... | 20:38 | ||
| diakopter | k | ||
| jnthn | (only noting this 'cus there's a proposed error text taht doesn't inlcude 'em :)) | ||
| diakopter | "something went wrong with your face. try again." | ||
| jnthn | The validator copies | 20:39 | |
| the function pointer from the process-wide registry into the in-memory record | |||
| of the extop call in that compunit, and invokes it. | |||
| ...and invokes it? :) | |||
| I'm guessing it's invoked during execution time? :) | |||
| diakopter | oh yes. :D | ||
|
20:40
colomon joined
|
|||
| jnthn | I'm not sure I follow the JIT extensions idea yet, but I'm fine with reserving > 32768 | 20:40 | |
| diakopter | >= | ||
|
20:40
jlaire joined
|
|||
| jnthn | yes :) | 20:42 | |
| In MVM_bytecode_extop_install I'm getting a slight sense of confusion over what there can be 28672 of. | |||
| The document so far implies that this is the maximum number *per compunit*. | 20:43 | ||
| But MVM_bytecode_extop_install seems to be trying to assign global numbers? | |||
| Whereas in reality we only care about names globally, and numbers are entirely per-compunit? | |||
| diakopter | if MVM_bytecode_extop_install is doing that it's a fossil | 20:44 | |
| jnthn | I'm not seeing that we need a global number, so it feels like we're doing more work than needed to enforce a restriction we needn't. ;) | ||
| OK :) | |||
| diakopter | .. I thought I cleaned all that | 20:45 | |
| jnthn | MVMuint16 opidx = tc->instance->nextcustomop++; | ||
| if (opidx == MAX_EXTOPS) | |||
| MVM_panic(tc, "too many custom ops!"); | |||
| That's the bit I'm referring too, fwiw | |||
| diakopter | oh yes. forgot to remove that. | ||
| TimToady | well, hey, there's a long tradition of VMs assuming things they shouldn't :) | ||
| jnthn | ah, good | ||
| I'm trying to assume different things I shouldn't :P | 20:46 | ||
| diakopter | it would've found that nextcustomop didn't exist pretty quickly | ||
| jnthn: oh wait. | |||
| yes there is a global thing there | |||
| because they're being stored in a table as well as a hash | 20:47 | ||
| jnthn | I'm not entirely clear on the proposed world interaction, but I'm comfortable enough with the overall design/approach that I think the exact factoring will fall out nicely as we work on this. | ||
| diakopter | so while it does need an opidx, it doesn't need a limit/max | ||
| jnthn | ok | ||
| Well, just make it bigger enough I guess :) | |||
| diakopter | jnthn: I can't remember how much I've talked through the p5interop design/thoughts with you yet | 20:48 | |
| jnthn | Not much, and doing so will be "interesting" given my general ignorance of P5 on the inside ;) | 20:49 | |
| diakopter | but... blizkost? | ||
| jnthn | *mumble* | ||
| sorear++ did the hard work ;) | |||
| I think I suppressed the rest ;) | |||
| #define REGI(idx) REG((idx)).i | 20:50 | ||
| Any reason these macros look different from the way we have 'em in interp.c? | |||
| I for one would rather not remember two syntaxes for one thing :) | |||
| Mentioned things aside, I find nothing disagreeable in here. | |||
| diakopter | fine I'll remove them :P | ||
| REG(3).i is fine | 20:51 | ||
| jnthn | So it can be untentativized some :) | ||
| diakopter | ok | 20:53 | |
| thanks | |||
| jnthn: there are plenty of optimization opportunities/ideas I've thought of, but I didn't include them there simply to keep it simple | 21:44 | ||
| but I wanted to let you know I'd thought about bunches of potential optimizations | |||
| FROGGS_ | "QAST::Var with scope 'lexcial' NYI" >.< | 22:29 | |
| diakopter | hee | ||
| jnthn | um...wat... | 22:31 | |
| FROGGS_ | $ nqp nqp-moar-cc.nqp -e 'my $fh := nqp::open("test.txt", "w"); say($fh.REPR)' | ||
| MVMOSHandle | |||
| \\o/ | |||
| diakopter | heh. | ||
| FROGGS_ | jnthn: just my way of typing today | ||
|
23:30
eternaleye joined
23:42
nwc10 joined
23:46
jnthn joined
|
|||