github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 August 2013.
00:34 colomon joined
diakopter FROGGS: ping 00:39
00:46 jnap joined
dalek arVM: 653ce49 | diakopter++ | / (2 files):
tabs to spaces and more compact trace format
 01:07
01:15 FROGGS joined 02:01 foo_bar_baz joined
JimmyZ .tell jnthn I doubt the gc bug are from compose in P6opaque.c, compose update st->size dynamically . 02:23
yoleaux JimmyZ: I'll pass your message to jnthn.
JimmyZ .tell jnthn which may be set wrongly, and cause the pointer offset wrongly 02:31
yoleaux JimmyZ: I'll pass your message to jnthn.
JimmyZ .tell jnthn I see nqp/parrot have spec.align, and MoarVM doesn't, Does MoarVM need it? 02:40
yoleaux JimmyZ: I'll pass your message to jnthn.
02:45 FROGGS joined
diakopter JimmyZ: I'm working on moving size to the MVMCollectable header, and making it per-object essentially 02:46
JimmyZ diakopter: oh 02:47
diakopter++
diakopter (which is what I thought jnthn said he wanted)
.. I don't understand how objects with the same STable can have different sizes 02:49
JimmyZ I can see the evil is from P6opaque 02:52
diakopter UM.
W.
T.
F.
oh. nm. 02:53
so.. compose can be called again on a single object? or on a type only 02:55
JimmyZ is not sure
diakopter bah... 03:00
I give up....
JimmyZ is not good at arithmetic 03:01
diakopter whee. nqp.moarvm gives parse errors.. :) 03:02
C:\\Users\\mwilson\\src\\MoarVM\\nqp-cc>..\\moarvm nqp.moarvm -e ";"
Confused at line 2, near ";"
panic
JimmyZ meant that it doesn't trig P6opaque yet :P 03:04
diakopter 2nd gc you mean
JimmyZ yeah, and 2nd gc 03:05
diakopter well it definitely hit P6opaque a lot b/c much of the nqp compiler ran 03:22
well, this is encouraging - that same invocation above takes 49ms or less
but parrot nqp it takes 77ms 03:23
(to hit the identical parse error)
JimmyZ :)
diakopter well, 64ms.
and parrot is generating the stack trace but moarvm isn't 03:24
so, meh.
04:53 FROGGS joined 05:21 benabik joined
JimmyZ hmm, I found threads.t hangs because the loop in finish_gc() can't be broken 06:02
06:12 not_gerd joined
not_gerd o/ 06:12
JimmyZ \\o 06:16
TimToady $ ../moarvm nqp.moarvm -e 'foo:' 06:20
Could not locate compile-time value for symbol foo
frame_name_162
$ ../moarvm nqp.moarvm -e 'my $x;' 06:21
Redeclaration of symbol $x at line 2, near ";"
panic
looks like progress :)
JimmyZ :)
well, nqp.moarvm eats memory, about 15M here 06:22
diakopter JimmyZ: 15M? 06:45
that's..... miniscule... parrot nqp uses 350MB
06:48 FROGGS joined
JimmyZ diakopter: ./npq eats 30M here 06:49
./nqp 06:50
dalek arVM/nativecall: 9510d6f | (Gerhard R)++ | src/6model/reprs/CStr.c:
Make CStr.c compile with dummy set_str()
 07:15
FROGGS diakopter: pong 07:16
dalek arVM/nativecall: ebb6b62 | (Gerhard R)++ | src/6model/reprs/ (4 files):
More bits and pieces, mostly search and replace
 07:44
not_gerd bye, #moarvm
07:44 not_gerd left
nwc10 jnthn: do you need to store the *byte* size of objects? In that, are there any objects that have sizes which are not multiples of 4 bytes? Or "the pointer size"? 08:23
08:31 donaldh joined
jnthn nwc10: Unlikely. But I'll go with byte size for now. 08:39
JimmyZ, diakopter: The problem is that mixing in causes a change of type, causing an object to point to a different STable than the one it did at the point of allocation, so now the size of the allocated memory and the size in the STable are out of sync. 08:42
JimmyZ jnthn: Does MoarVM need spec.align ? 08:43
jnthn JimmyZ: At some point, yes 08:44
JimmyZ: Not until we get to int32/int16/int8
etc.
JimmyZ thanks
08:52 donaldh joined 08:55 donaldh joined
diakopter jnthn: oh yeah... 09:56
you *did* say that.. but I forgot... :S
10:20 grondilu joined
diakopter jnthn: so will STable still have a "default size" member on its struct? 11:26
11:38 cognominal joined
jnthn diakopter: I'm planning to leave that, yes, so allocation will just copy that value into the collectable header. 11:38
diakopter: Planning to work on it soon-ish...
diakopter: Unless you already started on it? 11:39
11:51 jnap joined
diakopter jnthn: heh... started but then reset hard 12:07
jnthn
.oO( reset hard with a vengence )
 12:08
diakopter I was making it more complicated than it needed to be 12:10
jnthn It should involve patches to around 3 or 4 files I expect. 12:11
(6model.h to change flags to 16 bits and add the 16 bit size field, allocate.c to make sure the size is always written from the STable, collect.c to use the object header size) 12:12
diakopter yeah 12:30
dalek arVM/nativecall: 9e20546 | (Gerhard R)++ | src/6model/reprs/C (2 files):
Use *Body structures to determine storage bits and align
 13:24
arVM/nativecall: edc2519 | (Gerhard R)++ | build/Makefile.in:
Add dyncall to header search path
arVM/nativecall: 1f2b97b | (Gerhard R)++ | src/6model/reprs/NativeCall. (2 files):
Make NativeCall.o compile
JimmyZ hmm, libuv use stdint also on posix 14:27
15:09 cognominal joined
JimmyZ not_gerd: Do you mind to merge warnings branch? 15:11
jnthn What does the branch do? 15:12
Add a target that gives us more warnings to the Makefile?
15:13 FROGGS joined
JimmyZ jnthn: nope, just avoids some wanings 15:14
*warning
jnthn: github.com/MoarVM/MoarVM/compare/m.....warnings for a quick review 15:15
jnthn (void)data, (void)class_handle, (void)name, (void)hint; 15:16
*grmbl*
Can we not just disable that warning... :/
Also, is that portable?
Either way, an UNUSED(data, class_handle, name, hint); macro would be better... 15:17
Mostly, I just find such things noise, though.
JimmyZ linenoise use: #define __NOTUSED(V) ((void) V) 15:18
so should portable, and parrot uses it aslo 15:19
*also
nwc10 perl 5 uses it also 15:26
I'd trust perl 5 to be a lot more portable than linenoise, and more portable than parrot
JimmyZ ;)
nwc10 although possibly too portable (ie to platforms that MoarVM will never end up targetting) 15:27
FROGGS blasphemy!
nwc10 well, for starters I don't have access to any suitably old Crays
IRIX and Tru64 are about to be end of life
etc 15:28
JimmyZ BEOS
Does Perl5 have a JIT?
FROGGS the main target would be linux, osx, windows, and someday maybe android and similars 15:29
ohh, bsd of course too
JimmyZ android shouldn't be hard, since libuv supports it
FROGGS well, performance wise it is hard 15:30
nwc10 No. I think trying to write a JIT for Perl 5 would be even less successful than trying to write a JIT for Parrot 15:31
Solaris, AIX and HP-UX aren't dead
Although HP might be working on self destruction.
FROGGS true 15:32
nwc10 Solaris is safe as long as it helps pay for Larry Ellison's yachts 15:33
FROGGS I even have a opensolaris box somewhere...
nwc10 Sparc or x86_64?
JimmyZ I think trying to write a JIT for Parrot would be even less successful than trying to write a JIT for MoarVM :P
nwc10 I think that it ended up being documented somewhere that the problem with Parrot's JIT was that while it could do good work on code that comprised of simple OPs 15:35
as soon as code was made of OPs that had to call vtable routines to get into C
then it was crossing back and forth across the Parrot<->C boundary
and couldn't really do much better than generating code which was a sucession of method calls 15:36
hence why the Lorito plan came along - to replace a lot of the opaque (ro the JIT) C code with a way of implementing most of it in something that a JIT could understand
JimmyZ I doubt M0 won't be better. since it goes into another extreme 15:38
well m0 will end up a bit like lua though 15:39
nwc10 M0 was proposed in 2011, and hasn't got very far
and I suspect that it's more than just the NSA watching this channel (oh, and GCHQ), but I think I'll still post this: www.ohloh.net/p/parrot/commits/summary 15:45
Parrot hasn't been very active recently, and if it doesn't show an uptick, I doubt that M0 will progress from where it currently is 15:46
16:00 not_gerd joined
not_gerd o/ 16:00
diakopter not_gerd: speaking of m0..
not_gerd ;) 16:01
JimmyZ not_gerd: \\0
not_gerd: Do you mind to merge warnings branch? 16:02
not_gerd I never quite understood how m0 would magically solve most of parrots problems
(which is why I lost interest)
JimmyZ not_gerd: consider m0 is just another lua with CPS
not_gerd jnthn: casting to void is the idiomatic C way so silence unused warnings 16:03
(be it parameters, local vars, return values)
C programmers will probably recognize it 16:04
JimmyZ: I did not merge warnings yet because we need to do some decision-making on signed vs unsigned for some things
JimmyZ ok, when we got the decision :-) 16:05
not_gerd some things are unsigned, some things like indices are signed and check for non-negative
then, do we use signed or unsigned for our bool-equivalent? 16:06
JimmyZ speaking of parrot, they have 100+ branches, and never got the decision 16:07
odc _Bool is not portable?
not_gerd odc: microsoft :(
odc aha
not_gerd though they did recently decide to implemented some more of C99
odc then i vote int 16:08
jnthn Well, more importantly, the nqp::op set doesn't have a separate notion of bool
It uses (signed) integers in that place
So it makes sense to follow that.
odc i see
nwc10 beware of picking a not-a-bool type that is smaller than some of the things (ie expressions) that you are trying to assign to it
in case interesting flag bits fall off the top, and you always have "False" 16:09
not_gerd so I guess changing exists_key to return int64 instead of uint64 was the right call ;I
jnthn I'd say so
not_gerd nwc10: that's why _Bool was introduced
TimToady a uint1 fits nicely into either int64 or uint64 :)
JimmyZ so goes with uint1? :P 16:10
TimToady well, that's my view, but you'll have to argue with C to get it to have the same view :) 16:11
not_gerd typedef _Bool uint1; 16:12
[x] done
TimToady :D
JimmyZ btw: I'm +1 to merge ctypes also :P 16:14
odc but nwc10 says 1 bit is not enough :x
nwc10 no, I didn't say *that*. I said that emulating the real C99 bool type with an integer is risky if you don't take care 16:15
TimToady that's because C has braneded coercion semantics
nwc10 well, I wasn't clear that that was what I said
TimToady at least p6 has some different ideas about the right way to turn multiple bits into one bit :) 16:17
odc ok
TimToady but I realize talking about p6 is actually OT here :)
jnthn :P 16:18
TimToady where OT might mean Occupational Therapy...
jnthn I think it's on-topic enough that I want to keep using the MVMint32 typenames, though :) 16:19
Rather than adopting the C ones, so then I have to remember the Perl 6 names and the C names...
not_gerd well, we don't on the JVM, so there's prior art for not using them as well ;)
jnthn I woulda if I coulda :P
Java isn't exactly a language of choice :) 16:20
TimToady Java is a language of choice--it's just a bad choice...
jnthn Well, I was more meaning "doesn't give you much choice about anything", but there is that... :) 16:21
not_gerd another thing I've been thinking about is opcode reorganization 16:28
I'd like to collapse them into 4 banks and remove the double-indirection from the first one 16:29
a flat 16-bit space would probably be better for dispatch
keeping common ops in an 8-bit space is better for bytecode size, though
jnthn not_gerd: I've been pondering tossing the banks
not_gerd: They don't serve much purpose any more.
not_gerd: So then we'd have a single flat space. 16:30
not_gerd well, in the scheme I'm proposing they would serve to lose 1 byte in case of the primitive bank
jnthn huh... 16:31
not_gerd primitive ops would take 1 byte, ops from the other banks 2 and ext ops whatever they're supposed to use (3?) 16:32
jnthn That sounds like an unrequired complication...
not_gerd jnthn: could be more cache friendly
no idea if it's significant, but such things can be measured ;) 16:33
jnthn It could be, otoh it's probably less alignment friendly...
not_gerd does x86 care for 2-byte alignment? 16:35
4, 8 (and 16 in case of x64) are the important boundaries
jnthn I don't think it cares in so far as "will refuse to do it", but efficiency is another matter.. 16:36
not_gerd jnthn: well, you can make it care 16:37
and mms needs proper alignment
(did some inline asm and it was a pain to get those floats aligned right...)
but I was thinking about whether it's more efficient to ne misaligned by 2 than by 1 or 3 bytes 16:38
*s/ne/be/
nwc10 I think that modern (ie after my time) ARM CPUs can do 16 bit loads more efficiently if 2 byte aligned 16:39
TimToady bets his shorts on it... 16:41
not_gerd so, make int16 the unit of our 'byte'-code? 16:44
nwc10 has a long long way to go before he gets good at these puns 16:45
TimToady double your pleasure, double your pun... 16:46
nwc10 some are hard to a-void
TimToady would float the notion that a simpler solution is probably better in the absence of evidence to the contrary
not_gerd less complex is a real win 16:47
TimToady that's just how it struct me
jnthn not_gerd: I'm fine with a patch to remove banks. 16:49
not_gerd: I'm less convinced/comfortable with the 1/2/3 byte variable-length ops. 16:50
not_gerd jnthn: think of it as 1-byte ops with the 2-byte one taking another 1-byte argument
but there are arguments for 16-bit ops as well 16:51
JimmyZ I'd like to remove banks also :P
TimToady otoh, with 16-bit ops, you can do some analysis and add a few 16-bit ops that just happen to do two common operations
not_gerd the computed goto dispatch would like a flat op space, for what it's worth
TimToady any given architecture is probably going to be optimized for fetching instructions of a particular size, which may or may not map to fetching data of that size 16:52
diakopter the number of opcode instructions is small compared to the rest of the bytecode (operands) 16:53
nwc10 IIRC C compilers were getting upset with trying to dispatch of-the-order-of 65536 things. Of-the-order of 256 is fine
so a flat space may hurt for different reasons 16:54
or C compilers may be better now than 5-10 years ago
TimToady one can hope
one can also assume another increment of progress over the next 5-10 years
not_gerd it's not as if there's no prior art for variable-length op sets, though 16:55
diakopter I agree with jnthn that's it's a complication unneeded atm 16:56
not_gerd I assume we want a dense opcode set? 16:57
FROGGS diakopter: seen my /msg ?
TimToady dense is likelier to turn into a jumptable in C 16:58
otoh dense makes it difficult to keep related opcodes together as you add new ones, if you want to keep backcompat 16:59
not sure keeping them close is worth much though
diakopter not sure backcompat is worth much
not_gerd how much has the nqp op set changed over time? 17:00
(after 6model, taht is)
diakopter added many tens
if not hundreds
TimToady mostly you need a version number, so you can remap if necessary 17:04
jnthn dinner, bbiab
JimmyZ re ctypes, we can #define MVMint32 int32_t :P 17:05
diakopter the opset is quite arbitrary.. it's just driven by discrete needs of the compiler.. if an activity can be factored into an op, it is, so it doesn't have to be compiled to lots of ops, while you're writing the compiler. it's just a way of adding runtime calls; it doesn't really map to a "language"... many of the opcodes will cause millions of cpu instructions to run, each
JimmyZ jnthn: re ctypes, we can #define MVMint32 int32_t :P 17:08
17:08 colomon joined
diakopter not_gerd: did you find the irclogs where jnthn and I talked about nativecall type composition? 17:10
hmm, I may have "sent" those messages when yoleaux wasn't actually here
17:10 dalek joined
diakopter those messages = where I said you should look for that chat log 17:11
not_gerd diakopter: I saw them 17:13
the way I'm going about right now is fix the easy stuff and make it compile
then revisit and get it right
diakopter <- same for serialization 17:14
TimToady: the bytecode format had a version number from the start 17:16
I think it started at 667
(kidding)
not_gerd any objections to promoting MVMStorageSpec.bits to 32-bit? 17:24
jnthn not_gerd: Any reason to do so?
not_gerd: That thing gets passed by value, so keeping it compact is nice :)
not_gerd jnthn: 64k should be enought for anyone? 17:25
(actually, only 8k)
jnthn not_gerd: Given it's used for inlining native types into the bodies of opaques... :)
not_gerd jnthn: so we don't support inlining structures? 17:26
jnthn not_gerd: Not yet.
not_gerd well, do we want to?
jnthn not_gerd: I guess at some point arrays of compact structs may want to do that.
not_gerd then 8k might become an issue 17:27
why bits and not bytes, btw?
bitfield support planned as well?
jnthn int1, int2, etc.
VMArray can store those as bitfields, potentially.
not_gerd would it make sense to distinguish between bit size and byte size? 17:28
(thinking of long double)
(or 21-bit unicide chars)
*unicode 17:29
jnthn Not really, I don't think; it's a statement of need from the thing it's inlined into, not a demand for compactness.
not_gerd so 80-bit long double ands up with bits 96 on x86 and 128 on x64 as this is the storage they need to be correctly aligned 17:31
whereas uint1 would get a value of 1?
(just trying to figure out the edge cases) 17:32
or should long double get 80 bits and we then rouhd up to the correct multiple of align? 17:34
that would probably be the most correct one, semantically 17:35
jnthn There's (meant to be) an alignment thing in the storage spec also, which should be enough to convey this? 17:36
Or did I miss a detail?
not_gerd jnthn: well, I re-added it 17:38
there are 3 different, but related quantities: bit width, byte size and byte alignment
you can get the byte size from the other 2
so I guess we're good to go 17:40
jnthn \\o/
diakopter: Did you get anywhere with the object size thing?
not_gerd jnthn: should I just add gist.github.com/gerdr/882309b6203f14120473 to 6model.h? 18:11
diakopter jnthn: nope 18:18
dalek arVM/nativecall: 5471a7e | (Gerhard R)++ | src/6model/6model.h:
Add MVM_STORAGE_SPEC_BYTES() - we're going to need it
 18:19
jnthn not_gerd: wfm 18:20
diakopter: ok, I take it 18:21
diakopter ok 18:22
arnsholt not_gerd++ # NativeCall! 18:32
TimToady now if we could only get the non-native calls working... :P 18:33
diakopter they keep dropping when hopping 18:35
jnthn: remind me again what we said about p5 packages and how they'd know how to respond to .Str and such 18:38
it has escaped me.
again.
I'm writing it down this time, I promise
jnthn Dammit, I can't remember either :/ 18:39
diakopter hm, maybe I'll search the log for .Str
jnthn Was it just that Perl 5 types would have a meta-object that made them look sufficiencly like Perl 6 types?
Just like we do for Java types?
So they pretend to be ~~ Any 18:40
diakopter here it is
yeah but that just pushes it down a level
something has to set up the mappings
irclog.perlgeek.de/moarvm/2013-07-19#i_7348711 ff. 18:41
jnthn: u see that? 18:59
I'm hoping to discuss/review it sumoar
arnsholt diakopter, not_gerd: I'm working on a simple test file for native call functionality, ATM. Hoping to have it done tonight or tomorrow 19:01
not_gerd arnsholt++ 19:02
arnsholt 'Cuz I need it too, for the JVM stuff 19:03
My general idea is using that file to get the basics running, then using the NativeCall test suite to get the rest working once the basics are done 19:04
19:09 FROGGS joined
dalek arVM/nativecall: 55df863 | (Gerhard R)++ | / (4 files):
Import Parrot's ops/nqp_dyncall.ops as core/nativecall.c
 19:59
arVM/nativecall: f7e74e9 | (Gerhard R)++ | src/6model/reprs/C (4 files):
More bits and pieces
not_gerd bye, #moarvm 20:00
20:00 not_gerd left
diakopter r: not_gerd++ 20:03
gerd++
er.
why did I prefix that with r:
jnthn back 20:04
diakopter jnthn: pending question to you ^
er, request
jnthn looks at the clog 20:05
(that you linked) 20:06
diakopter in Oppressive Regime, ir clogs you
jnthn: esp don't miss 23:26FF 20:08
ff
jnthn Hmm 20:10
Grr, hard problems are hard :)
diakopter well we've already got CPS, of sorts since the current/return/next frame is accessible from tc 20:12
jnthn Yeah
Well, we use that for smart_stringify already
diakopter has forgotten
jnthn It's possible that "" stringification of a Perl 6 thing from Perl 5 wants to use very similar semantics to that... 20:13
diakopter yeah, but...
jnthn It's just that we're not in a Moar runloop at that point, probably... 20:14
diakopter that means many many more ops need to become non-local returning possibly
jnthn How so?
diakopter hrm.
jnthn I think we discussed that $p6-thing . $p6-thing in Perl 5 would just be two coercions to string and then the default Perl 5 . for example... 20:15
diakopter ? 20:20
p5 operations on p6 objects aren't the problem - the other way is 20:21
well 20:22
my brain is need fried food 20:23
lizmat you are what you eats 20:27
jnthn diakopter: It was just those 3 files needing changes :) 20:46
diakopter++ # backtrace better 20:48
dalek arVM: 8b04b25 | jnthn++ | src/6model/6model.h:
Add per-object size to MVMCollectable.

Not yet used for anything.		 20:49
arVM: f0766e0 | jnthn++ | src/gc/allocation.c:
Start recording collectable size in header.
arVM: 9e0d1e4 | jnthn++ | src/gc/collect.c:
Use per-object size in GC.

Turns out to lead to simpler code as well as being more correct.
jnthn is happy when a change like that turns out effortless 'cus stuff is factored into the right places... 20:51
FROGGS there is nothing better than a good design 20:56
designer(s)*, even
diakopter so.. what's the next blocker 20:59
jnthn a skype call, bbs
diakopter is tickled to imagine jnthn trying to explain to the rakudo class the finer points of the qast->mast 21:01
FROGGS nqp nqp.moarvm -e '1' 21:25
Error while reading from file: Malformed UTF-8 string
$ ../moarvm nqp.moarvm -e '1' 21:26
Too many positional arguments; max 1, got 4
please ignore the first one :o)
diakopter: that `max 1, got 4` is that about the void thing? 21:27
void op*
dalek arVM: 4a62522 | jnthn++ | nqp-cc/tools/build/moarqast.pl:
QAST -> MAST needs NQPHLL for lineof.
 21:38
arVM: e839e37 | jnthn++ | nqp-cc/tools/build/Makefile.in:
Missing Makefile dependency.
 21:55
arVM: 100dcc6 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
Missing null check.
jnthn C:\\consulting\\MoarVM\\nqp-cc>..\\moarvm.exe nqp.moarvm -e "say(42)" 21:56
mbc NYI
\\o/
This means that it manages to create a MAST tree. 21:57
Now I "just" need to write up MAST => bytecode, and invoking of the result. 21:58
23:01 BenGoldberg joined, BenGoldberg 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!