01:20 colomon joined
timotimo i wonder if we should turn const_i64_16 + p6bool into something "simpler"? 02:13
i think p6bool is still a function call when we jit, so maybe a getspeshslot would be the right thing to do? 02:14
gist.github.com/timo/2f113b1e8536c8764726 - a tiny bit painful %) 02:17
02:42 FROGGS joined 03:07 vendethiel joined 05:52 vendethiel joined 07:45 vendethiel joined
FROGGS O.o 07:52
root@debian-mipsel:~/nqp# perl Configure.pl --prefix=/root/MoarVM/install 07:53
Found /root/MoarVM/install/bin/moar version 2015.06-83-gd0f568b, which is new enough.
Bus error
Cleaning up ...
make: *** [gen/moar/stage1/nqpmo.moarvm] Bus error
nwc10 real hardware?
FROGGS nwc10: no, qemu
nwc10 OK, then my inital thought of "alignment constraint" seems to be wrong, as I *think* that qemu doesn't attempt to force misalignment strictness 07:54
FROGGS btw, the intel itanium server I was supposed to get last week turned out to be an intel xeon 32bits :o(
nwc10 ie it doesn't emulate the hardware for the behaviour for *incorrect* code. Correct code is hard enough 07:55
oh :-(
FROGGS hmmm, maybe I just buy something like that? www.ebay.de/itm/121465305471 07:56
okay, it does not come with a hard disk... 07:57
hmmm, there are also units from Carambola (which look like a raspberry), but they only have 32MB RAM 08:00
08:08 vendethiel joined 09:43 Peter_R joined
FROGGS nwc10: any idea where I could start looking? 09:58
I have no idea how to debug this
I think that's a start: 10:08
Program received signal SIGBUS, Bus error.
0x77d6c360 in set_num () from /root/MoarVM/install/lib/libmoar.so
recompiling with debugging information now
nwc10 OK, that probably *is* alignment 10:11
FROGGS btw: "your CPU can't read unaligned values for any of int32 int64 num64"
nwc10 OK, odd. So the default looks like it's "I don't know this CPU, so I'm going to be defensive" 10:12
this bit of build/probe.pm 10:13
# ARMv5 and earlier do "interesting" things on unaligned 32 bit
# For other architectures, play it safe by default.
# Updates welcome.
so it ought be safe by default, and not doing it
*however*, IIRC on the ARM boards I had access to, the OS did some fixups 10:14
(a slowdown, but a cover up)
so it might be we have some code that isn't aware of unaligned, and needs to become a memcpy
FROGGS aha
nwc10 based on grep, I'm going to guess that it's # ARMv5 and earlier do "interesting" things on unaligned 32 bit 10:16
# For other architectures, play it safe by default.
# Updates welcome.
oops 10:17
based on grep I'm goingto guess that it's set_num in P6num.c
default: ((MVMP6numBody *)data)->value.n64 = value; break;
but if it is that would mean that ->value is misaligned, and I don't know why that would be.
FROGGS sadly it takes a while until we know 10:18
slow things are slow 10:19
nwc10 and ccache doesn't help the first time 10:20
FROGGS ccache?
nwc10 ccache.samba.org/
FROGGS ahh
yeah
nwc10 very useful.
FROGGS I see 10:21
11:49 vendethiel joined
FROGGS yay, rebuild finished 12:54
nwc10: you are right: 12:55
set_num (tc=0x412400, st=<optimized out>, root=0x771fceac, data=0x771fcebc,
value=1436100926.6184793) at src/6model/reprs/P6num.c:52
52 default: ((MVMP6numBody *)data)->value.n64 = value; break;
nqp-m: say(nqp::time_n()) 12:56
camelia nqp-moarvm: OUTPUTĀ«1436101018.72548ā¤Ā»
FROGGS so why do we get a bus error? 12:57
timotimo can you print offsetof the value thingie? 12:58
FROGGS timotimo: do you mean ALIGN_OF by any chance? 12:59
timotimo um
i forget :) 13:00
FROGGS (gdb) p ALIGNOF(value)
A syntax error in expression, near `{ char c; value _h; } *)0)->_h) - (char *)0)'.
timotimo :o
FROGGS so our ALIGNOF macro is buggy here? 13:01
timotimo i didn't know alignof wasn't built-in
FROGGS here: /home/froggs/dev/MoarVM/src/moar.h:54:#define ALIGNOF(t) __alignof__(t) 13:02
/home/froggs/dev/MoarVM/src/moar.h:57:#define ALIGNOF(t) __alignof(t)
/home/froggs/dev/MoarVM/src/moar.h:60:#define ALIGNOF(t) ((char *)(&((struct { char c; t _h; } *)0)->_h) - (char *)0)
ahh wait 13:03
nwc10 I guess the alignment question is, what is
&((MVMP6numBody *)data)->value.n64
FROGGS I'm dumb
timotimo ah, right, we can just do it like that, too
i didn't realize either :)
it's really warm in my apartment
and i'm afraid opening the windows would only make it even warmer 13:04
FROGGS nwc10: how do I check that?
the ALIGNOF macro seems useless
nwc10 by the way, it is an illusion that I'm currently online continuously
I think
FROGGS (gdb) p ALIGNOF(double) 13:05
A syntax error in expression, near `{ char c; double _h; } *)0)->_h) - (char *)0)'.
nwc10 print &((MVMP6numBody *)data)->value.n6
at the gdb prompt
arght
print &((MVMP6numBody *)data)->value.n64
I missed that
timotimo yeah
just print the addresses and compare
nwc10 ALIGNOF is a compiler macro, *and* would tell you the correct answer for alignment
FROGGS (gdb) p &((MVMP6numBody *)data)->value.n64
$3 = (MVMnum64 *) 0x771fcebc
nwc10 what the problem here, is what's the actual answer
mmm, seems to be 4 byte aligned 13:06
FROGGS it is a 32bit system fwiw
nwc10 stackoverflow suggests that doubles need to be 8 byte aligned 13:07
timotimo so it'd be enough to put that value in our probe thingie? 13:09
maybe along with other things we now know about that particular platform?
nwc10 no, because our probe is not being used for that write
my question, and might be to jnthn
jnthn: how come that value is 4 byte aligned, not 8? Where is it coming from
timotimo i thought having the alignment values in the probe would give us different layouts for the objects, like MVMP6numBody? 13:10
nwc10 OK, expeimentatio on ARMv7 is that on that, one can write and read doubles at 4 byte alignment without error 13:11
my ARMv6 is 1500km away
timotimo hmm
FROGGS lol, I can do the failing assignment in gdb and it works O.o 13:19
is that normal?
nwc10 I think so. I think that at the gdb command line, it fixes up unaligned access 13:20
FROGGS ahh
timotimo ... how can it fix up unaligned access?
nwc10 as far as I can work out, on ARMv7, I can't tell if it needs to be aligned without writing assembler
timotimo does it split up the double and do "aligned" access at the byte-level? 13:21
nwc10 because it seems that my C test program doesn't manipulate a double, but two 32 bit integer registers
timotimo: I believe yes
timotimo ack
nwc10 anyway, the bit I'd love doubleplusjnthn to (help) answer is "is the thing we're accessing supposed to be properly aligned for the CPU? Or is the code here supposed to "cope" and deal with packed structures?" 13:22
also, currently I don't hugely want to push the Pi into doing builds, as it's playing at being the wireless base station, and the power supply isn't 100% good enough for that, even with the CPU idle.
timotimo ack
that's a pi2, yeah?
nwc10 and the old Pi, with the ARMv6, would probably be better at finding these things 13:23
yes, it's a Pi2
jnthn: Bother: 13:34
struct MVMP6numBody {
/* Float storage slot. */
union {
MVMnum64 n64;
that's only going to be 4 byte aligned on a 32 bit system. (he says with 80% confidence)
(that is from memory)
struct MVMCollectable -- 3 * 4 bytes 13:36
FROGGS nwc10: gist.github.com/FROGGS/4f1fac6ac4a47d555981
nwc10 struct MVMObject -- + 4
oh, I'm in the other 20%. I was wrong 13:39
OK - so, that bugger *should* be aligned.
why isn't it
FROGGS: what is sizeof(MVMObject) ?
and what 6model class is the actual object that is being passed in and getting the SEGBUS 13:42
SIGBUS
also, at some point i might "vanish" without warning 13:43
FROGGS np 13:45
nwc10: sizeof(MVMObject) is 16 13:51
ohh dang, my sample code used %d on the double >.< 13:53
nwc10 sizeof(MVMObject) of 16 means that MVMP6numBody should awalys be aligned. So what is passing in a pointer that isn't aligned? 13:57
FROGGS gist.github.com/FROGGS/43c323ed4ef0b57398e6 14:02
it is a P6num
timotimo nwc10: "passing in a pointer that isn't aligned" isn't even the problem, is it? 14:10
we're doing struct access at that point
14:11 nebuchadnezzar joined 14:16 ggoebel joined
FROGGS (gdb) p *(MVMP6numREPRData *)0x41e128 14:19
$25 = {bits = 64, storage_spec = {inlineable = 1, bits = 64, align = 8, boxed_primitive = 2, can_box = 2, is_unsigned = 48 '0'}}
dunno if that is worth anything
I does not help that I don't know what I am doing :o(
dalek arVM: 034551e | (Daniel Dehennin)++ | build/Makefile.in:
Add $(LDFLAGS) to minilua build command

The minilua is only used during build time but the Debian blhc reports the hardening flags as missing.
  * build/Makefile.in (3rdparty/dynasm/minilua@exe@): Add $(LDFLAGS) to
   silent Debian blhc.		 14:28
arVM: 8f1ed93 | FROGGS++ | build/Makefile.in:
Merge pull request #228 from baby-gnu/add-LDFLAGS-to-minilua-build

Add $(LDFLAGS) to minilua build command
14:30 LLamaRider joined
FROGGS so, I can't even do this: 14:39
Program received signal SIGBUS, Bus error.
set_num (value=1436107137.947197, data=0x771fcfa4, tc=<optimized out>, st=<optimized out>, root=<optimized out>) at src/6model/reprs/P6num.c:53
53 ((MVMP6numBody *)data)->value.n64 = (MVMnum64)3.14;
I think I know what is going on now... 15:03
we are assuming that ALIGNOF(void *) is at least as big as ALIGNOF(double), which is not true here 15:10
and that means that the OBJECT_BODY is giving us wrong answers here
and in about 2.5 hours I'll know :o( 15:14
timotimo it doesn't confuse me so much that the code would generate a boxing + istrue ... it confuses me a bit more that the optimize_istrue_isfalse optimization doesn't trigger and turn the istrue into an unbox_i 16:45
(talking about gist.github.com/timo/2f113b1e8536c8764726 in case you didn't see it) 16:46
nwc10 FROGGS: I'm temporarily back 17:28
if I add this in set_num and get_num: 17:29
+ assert(((unsigned long)&(((MVMP6numBody *)data)->value.n64) & 7) == 0);
I see assertion failures if building as x86
badness happens from MVM_box_num -- paste.scsys.co.uk/492254 17:32
FROGGS aye 17:33
that's the same spot
nwc10 but I haven't figured out what sort of object it is 17:35
SIGNAPPYCHANGE 17:38
japhb
.oO( SIGNAPPY: This signal may be caught and handled; if ignored, an internal timer will start. If not handled by the time the timer expires, child process will emit SIGSCREAM. )
 17:48
FROGGS what I think what happens: MVMObjects get allocated on a four byte boundary, because pointers just can 17:49
nwc10 the big problem is if the core dump overflows storage
FROGGS and OBJECT_BODY(root) will return &root+16, which is wrong for P6num
because the body will be 8-byte aligned
because it is a struct holding a union to double+float 17:50
nwc10 food is here, and I'm sitting at the table with the laptop
FROGGS :D
nwc10 I suspect that the best fix is for reprs to know what their alignment constraint is, and pass that to the allocator
FROGGS aye
nwc10 and the nursery allocator pads with 4n bytes if needed
FROGGS the repr knows the alignment of the REPR_data already I think 17:51
nwc10: enjoy your fodd
food*
nwc10 and I *think* that the gen2 will always start the memory block at maximal alignment, and due to correct object sizes will always maintain correct alignment
thanks
&
18:27 brrt joined
timotimo yeah, the alignment for gen2 is a bit stronger than for nursery and such 18:28
nwc10 the only thing that's bugging me about attempting to pad the nursery is that the GC has to walk along the nursery intropsecting things. 19:01
so there kind of has to be a way to have the padding be a value that would be illegal in a union sc_forward_u 19:02
timotimo yes, it uses the "size" attribute for that
and it expects that after stepping one "size" step it finds the header of the next object
nwc10 and if there's padding, it won't
FROGGS the dirty patch I applied right now seems to let me get further btw 19:03
nwc10 but I *think* that it might be viable to put a sentinal value in the 4 bytes, assuming a sentinal exists
however, that's "optimsiation"
FROGGS but yeah, having holes in the nursery might not be ideal 19:04
nwc10 the simpler fix (for now) is to align always
timotimo yes 19:08
i wonder: how much do we tend to lose when we do that?
that probably depends entirely on what a given workload allocates
nwc10 This is definately the "do it later", but I think it would be viable to store an illegial serialisation context as padding (on allocation) 19:13
and change it to an illegial forwarding pointer at the pass that writes forwading pointers. 19:14
one illegal forwarding pointer would be to the exaxt same address
timotimo OK, but when we copy stuff over from the old nursery to the next we need to "do it again"
the padding
nwc10 (NULL already has meaning)
timotimo isn't NULL only valid when there's also the flag "has legal forwarding pointer"? 19:15
nwc10 good point, yes, we'd need to re-calculate whether padding is needed
mmm. true
"do it later"
timotimo right
nwc10 let's just pad always on (at least) MIPs
timotimo we'd only need that on such bizarre platforms anyway ;)
nwc10 heck, on anything that says it needs alignment, even ARM
19:18 zakharyas joined
FROGGS but only if e.g. ALIGNOF(double) > ALIGNOF(void *) 19:20
nwc10 technically other things (eg long long) might have a greater alignment constraint than void * 19:26
but in the real world, I'm only aware of double (on some platforms) (and long double (on some platforms)) being the real problems 19:27
of the C types
19:38 brrt joined
nwc10 brrt: "Internet 1.0" was the UTMS dongle in my laptop, and my laptop sharing it as wifi 19:45
"Internet 2.0" was persuading the Raspberry Pi to do that job instead 19:46
and now my laptop doesn't have an annoying dongle dangling from it
and everyone else still has Internet even when I close my laptop
brrt aha 19:49
cool
on holiday, or permanent?
brrt had internet from his phone for about a year 19:50
phone company capped it to 128kbps i think? that was an interesting year
nwc10 hoilday. 19:51
well, visiting parents, but they usually only have 1 device which the UTMS dongle plugs into.
brrt right 19:54
raspberry pi's are pretty nice
timotimo oh hey brrt :) 20:14
brrt hi timo :-)
timotimo warmth is kind of keeping me from doing cool stuff
makes sense, right? 20:15
it's finally beginning to cool down a tiny bit
as in: hotter inside than outside
bbiab
brrt yes, it has been hot; although today we had at least two thunderstorms over here 20:20
y'know, the government of germany really ought to get some recognition for the energiewende thingy 20:21
that is changing the world 20:26
20:28 colomon joined
brrt remind me to do some serious cage cleaning on the 'old' JIT one of these days 20:31
timotimo oh, really? 20:39
in germany itself, the energiewende is constantly being called a failure
brrt people will always complain 20:40
it's a huge success
timotimo good to hear
brrt (i mean on a global scale)
timotimo well, you'd know much better than me for multiple reasons
brrt considering that residential solar power is as cheap or cheaper-than gird power on most parts of the globe by now (and considering the german feed-in tarriff was immensely important for that to happen) it's impact is already enormous 20:41
and that's just solar :-) 20:42
timotimo the feed-in tariff was about feeding power back into the grid from your home? 20:45
and getting money for that?
brrt yes 20:46
it used to be quite generous, not so much anymore
i do believe you still have net metering, which is also a subsidy of sorts 20:47
it appears i made some error in dynasm 20:53
although it's not obvious where
timotimo a friend just explained to me that the energiewende stuff caused consumers to have to pay more overall, but the industry that actually uses up the most energy all in all by far didn't get any fee increase 20:54
that doesn't seem fair :\
brrt i'm ambivalent 20:55
no
it's not fair
yes, it's reasonable
why is it reasonable? because people depend on industry a): for their jobs b): for their goods
it is in social terms more useful to have industry use energy than people
who would use it for warming their pools 20:56
timotimo people have legit reasons for wanting cheap energy
brrt i.... am a resident of a country which has both expensive energy *and* a natural abundance of it 20:57
i find it personally difficult to accept the notion of fuel poverty in an advanced economy
i mean, you can change lightbulbs to LEDs for 5 euros, save 90% of energy used for lighting 21:01
timotimo what percentage of energy use comes from lighting 21:04
?
brrt significant amounts, if you use incandescent light bulbs :-)
timotimo hm 21:05
what about halogen light bulbs?
and energy saving lamps? 21:07
brrt halogens are only a little better than incandescent light bulbs
LEDs are by far preferable 21:08
not entirely sure about energy saving lamps 21:22
maybe the netherlands is just exceptionally rich (in european terms)
dalek arVM/even-moar-jit: 8572a73 | brrt++ | src/jit/expr (3 files):
Define expression op structure

Add a new (idx) address computation mode for finding the index of an array (used e.g. by getting data from the frame args array).		 21:25
arVM/even-moar-jit: 9ce6c1f | brrt++ | src/jit/expr. (2 files):
Initial traverser algorithm
Heuristic branch merge: pushed 38 commits to MoarVM/even-moar-jit by bdw 21:26
brrt i'm going to remove the option of specifying your own lua 21:28
it can do no good things
and creates problems when you want, e.g. to use system lua and the build system wants to *build* it 21:29
(Makefile)
..... hmmm 21:31
timotimo huh 21:32
21:43 dalek joined
brrt bbiab 21:48
22:00 TEttinger joined 22:15 colomon_ joined 23:45 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!