github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:47 Kaiepi left 05:28 tobs joined 06:36 MasterDuke left
nwc10 good *, #moarvm 08:04
08:25 sena_kun joined
nwc10 I'm not so sure about the good part. I'm having flashbacks to ARM porting 08:47
08:49 domidumont joined 09:00 domidumont left 09:43 leont joined 10:37 Kaiepi joined
timotimo you can't spell moarvm without ARM 11:23
lizmat
.oO( waiting for the video: ARM.mov }
 11:29
11:45 Altai-man joined 11:48 sena_kun left 13:02 domidumont joined 14:20 MasterDuke joined 15:46 sena_kun joined 15:48 Altai-man left
Kaiepi it took a couple days to figure out exactly how to get this to work in combination with the I/O event loop, but i got cancellable, async DNS queries with LDNS working 16:46
hopefully WinDNS works out ok too... 16:47
timotimo Kaiepi++ 16:50
moritz Kaiepi++ 16:55
timotimo Call::Name ??? 17:14
hmmm
(oh, unicode don't work in my irc client at the mo)
there's a little anchor emoji
jnthn Which means it's sjunk :) 17:15
*sunk
timotimo :D
do we want some attributes of these nodes to be part of the dump? it's quite bare at the moment
17:23 zakharyas joined
timotimo i hope we can come up with something good for "this has multiple roles, and the roles can all contribute something to the dump result" 17:24
changing stuff in Raku/ast/ seems to give trouble unless you "make clean" 17:31
17:47 zakharyas1 joined 17:49 zakharyas left
nwc10 oooh, I have a slightly hacked up sparc32 build that fails the same tests as ppc32 18:05
ie, grr, some of our tests are naughty and assume 64-bit things
and some assume little endian things 18:06
spectests
I will educate these tests (at some point)
we make a few alignment assumptions about "it's OK to load 32 bit values at 16 bit offets" 18:07
and clearly a *lot* of 64 is OK at 32
(can't yet get sparc64 to play)
hacked, because it seems that both libtomath and dyncall can't cope with a build with -m32 on a sparcv9 system 18:08
and I've not yet worked out what is buggy - them, or gcc in how it declares things.
Geth MoarVM/sparc: 92ef5d7f8e | (Nicholas Clark)++ | 5 files
sparc32 does not support unaligned 32 bit reads or writes.

Our bytecode is 2-byte aligned, but we need to read 4-byte values. sparc will SIGBUG if asked to perform a misaligned read.
We also need to add the same hack as s390 to get a definition of AO_fetch_compare_and_swap_full ... (9 more lines)		 18:56
nwc10 SIGBUG. oops :-)
Geth MoarVM/sparc: 87ad486f30 | (Nicholas Clark)++ | 5 files
sparc32 does not support unaligned 32 bit reads or writes.

Our bytecode is 2-byte aligned, but we need to read 4-byte values. sparc will SIGBUS if asked to perform a misaligned read.
We also need to add the same hack as s390 to get a definition of AO_fetch_compare_and_swap_full ... (9 more lines)
18:58 sena_kun left 19:16 domidumont left
nwc10 Question. For this: 20:03
class MoarVM::Handler { has int32 $!start_offset; has int32 $!end_offset; has int32 $!category_mask; has $!action;
oh thanks irssi
class MoarVM::Handler {
has int32 $!start_offset; 20:04
has int32 $!end_offset;
has int32 $!category_mask;
has $!action;
what has decided that for the P6Opaque, it's fine for the MVMObject that is $!action to be at offset 20? 20:05
when ALIGNOF(MVMObject *) is 8
ie, why aren't we padded to 24?
timotimo dunno, the algorithm for that is in P6Opaque.c in the compose function it hink?
nwc10 well, it seems to start with: 20:08
align = ALIGNOF(void *);
which is looking good.
so I'm failing (so far) to see how it gets less strict 20:09
timotimo honestly ... gdb and single-step or lots-of-printf
nwc10 I should to go bed and restart with a fresh head
but if it *is* flashbacks to ARM (5 or 6 years ago)
timotimo and at some point we'll jit on arm, too 20:10
nwc10 then it will be something about sizeof(the object header) being a multiple of 8 bytes, or off-by-4
and the variant where the opaque object body is referenced via a pointer instead of directly inlined
being "the other"
timotimo ooh, i didn't consider the object header 20:11
nwc10 what we have currently is very carefully bodged
timotimo especially fun since we also have actual_data, which will not live at an offset dictated by an object header
nwc10 so that the alignment of the object header is correct on x64_64, i386 and arm
er, is "correct" enough that the two ways of storing somethign - opaques I think - has the same alignment
and all other platforms don't care as much 20:12
(so far) 20:14
(gdb) print sizeof(struct MVMP6opaque)
$3 = 32
mmm, that looks safe
timotimo ah, that's essentially the offset of the data we have in the actual struct? 20:15
nwc10 I think I understand the question, and if so, the offset (on sparc64, and probably all 64 bit platforms) is 32 byts in 20:16
or, if you have been indirected using
void *replaced
0 bytes in.
which is good.
because malloc damn well ought to be aligning on 16 bytes.
timotimo it should 20:18
ok, that does sound good
it's exploding somewhere at runtime trying to access the $!action pointer in that class? 20:19
i really gotta get in the kitchen make dinner damn
nwc10 yes, do this
I need to go AFK too
on sparc64 it explodes because of MVM_ASSIGN_REF
because it's doing a pointer read or write (I forget which) at not-8-byte-aligned 20:20
timotimo ah
nwc10 but I think that the source of this not-8-byte-aligned is deserialize_repr_data
timotimo it could in theory also be the header bit it sets?
nwc10 "header bit" - I don't understand this question
and I am also stoping you eating 20:21
timotimo ah, it doesn't set a bit; it does the inter-generational pointer thing?
nwc10 I think that I'm explaining it badly, and probably this is all better tomorrow
I believe that we're composing pointers to objects at 4 byte alignment 20:22
timotimo well, i'm glad you have a sparc machine to play with :)
nwc10 but the first place that the sparc64 machine realises this is much later in MVM_ASSIGN_REF
timotimo has looking at the disassembly, or reducing the optimization amount, been any help? 20:23
nwc10 it's this lot: cfarm.tetaneutral.net/machines/list/
timotimo i imagine valgrind would also have something to say
or perhaps rather use asan
but it should be a thing these libs do, right?
but yes, i should actually go towards cooking, darn
nwc10 valgrind doesn't do sparc 20:24
(seems to do *everything* else, including s390x/linux)
timotimo i don't even know what s390x is :) :)
nwc10 IIRC it's IBM mainframes
lizmat yeah 20:25
nwc10 but ASCII
timotimo rather than ebcdic, right?
nwc10 yes, rather than EBCDIC
which is a very rude word
timotimo is ebcdic also 8 bit characters?
nwc10 yes. but oh my
timotimo i wonder what exactly you have to do to support ebcdic
nwc10 and *then* once you are fine with 'J' - 'I' being > 1
and '0' > 'A' 20:26
and the other fun and games
you get to UTF-EBCDIC
timotimo oh lord
nwc10 and, dammit, '~' having three different values dependig on the code page
OK, this is nuts (and probably a bug) - `clang -m32` works 20:34
but as soon as I add -O it bombs out with an error in a header
(specifically /usr/include/bits/stdio-ldbl.h which seems to relate to using <stdio.h> but clang is forcing sizeof(long double) to be 8) 20:35
if I understand the comments correctly
(have not played with all the command line options to see what clang is defining to do daft things with long doubles)
(but I do remmeber stupidity years ago on gcc compiler farm machines where some (sparc64 again I think) were set up with long doubles being 12 bytes, and others with long doubles being 16) 20:36
everything is hateful.
I should go to bed :-)
lizmat sleep well! 20:40
21:05 zakharyas1 left
timotimo phew, the payload has been delivered to the furnace 21:10
dang, that took me half an hour already? 21:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!