github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:34 lucasb left 05:51 leont left 07:08 domidumont joined, p6bannerbot sets mode: +v domidumont 07:38 robertle joined 07:39 p6bannerbot sets mode: +v robertle
Geth MoarVM: 652b2f4a7e | (Stefan Seifert)++ | 5 files
Make space for BINARY_ENDIAN_(LITTLE|BIG|NATIVE) in (write|read)(u?int|num) ops

I missed the part of the specification that besides using little and big endian allowed for just using native encoding. This means a single bit is not sufficient and we need two bits for encoding endianness. Therefore we need to adjust the size values. To get around bootstrap issues we treat the size value different depending on the little endian flag being set, as all current users are missing that but are going to set it.		 08:22
MoarVM: 73b079c375 | (Stefan Seifert)++ | 3 files
Support endian switching in writeu?int
 08:23
MoarVM: b8ba4707c8 | (Stefan Seifert)++ | 2 files
Support endian switching in readu?int
08:33 zakharyas joined 08:34 p6bannerbot sets mode: +v zakharyas
nine robertle: the latest commits in MoarVM + nqp could be enough to get us going on big endian systems 08:37
nwc10 MoarVM panic: Internal error: zeroed target thread ID in work pass 08:39
make: *** [gen/moar/stage2/QASTNode.moarvm] Error 17
make: *** Waiting for unfinished jobs....
that was with MVM_SPESH_NODELAY=1
trying again without
OK, without, it passes tests 08:45
er, nqp *builds* and passes tests
tests pass with MVM_SPESH_NODELAY=1
ASAN makes no comment either way. Just the paninc 08:46
I can't type
09:18 lucasb joined, p6bannerbot sets mode: +v lucasb
robertle nine: I just tried moar gb8ba4707c and nqp g176960303, but still get a "Bytecode stream version too high" during nqp build 09:47
are these the right versions to try? should I use some branch?
nine those are the commits 10:06
10:57 domidumont left 11:22 leont joined 11:23 p6bannerbot sets mode: +v leont 12:20 zakharyas left 12:45 domidumont joined 12:46 p6bannerbot sets mode: +v domidumont 12:47 domidumont1 joined, p6bannerbot sets mode: +v domidumont1 12:49 domidumont left 12:53 domidumont joined 12:54 p6bannerbot sets mode: +v domidumont 12:55 robertle left, domidumont1 left 13:49 robertle joined 13:50 p6bannerbot sets mode: +v robertle 14:04 zakharyas joined 14:05 p6bannerbot sets mode: +v zakharyas
dogbert2_ isn't this test a tad unnecessary? : github.com/MoarVM/MoarVM/blob/mast...rp.c#L6239 14:16
timotimo probably is 14:18
dogbert2_ perhaps it's optimized away
timotimo probably
14:39 brrt joined 14:40 p6bannerbot sets mode: +v brrt
brrt \o 14:42
dogbert2_ hello brrt 15:02
brrt ohai dogbert2_ 15:06
timotimo brrt: look over in #perl6 for someone who seems to have a good optimization opportunity for the jit 15:08
brrt timotimo: cool 15:09
15:18 domidumont1 joined, p6bannerbot sets mode: +v domidumont1 15:20 domidumont left 15:25 moony_ joined, p6bannerbot sets mode: +v moony_
Geth MoarVM/jit-expr-float: 74a6f5addb | (Bart Wiegmans)++ | 3rdparty/dynasm
[DynASM] Take in REX encoding fix

A recent fix in the way that DynASM encodes OPTREX and MARKREX annotations for large opcodes fixes SSE2 variable register encoding.		 15:35
MoarVM/jit-expr-float: 85ec95b8e2 | (Bart Wiegmans)++ | 5 files
[JIT] Use bitmap for free register set

Registers are represented as small integers. A bitmap supports all the operations we need for registers in constant time and space.
brrt next thing is to store a bitmap per register class 15:36
15:37 moony_ left
Geth MoarVM: 0d5f389c35 | (Timo Paulssen)++ | src/spesh/candidate.c
Don't Dump "Facts" in "Before" Part Of Spesh Log
 15:48
nine Oh how I hate that Debian release name nonsense. "Debian Power PC images updated with Etch and Lenny". Ah, yes, that must mean that they are....some releases (or not). No idea how current whatsoever. 15:49
brrt nine: i hear you 15:51
robertle nine: where did you get that? the sentence does not seem to make much sense even from a grammar point of view 15:52
nine robertle: oh that's no direct quote, so the grammar screw up is mine alone. 15:55
robertle ah, ok then 15:58
nine I meant this: blog.aurel32.net/46 15:59
The comments' dates suggest that it's more outdated than people.debian.org/~aurel32/qemu/powerpc/, so I go with the latter
Alas Failed to fetch ftp.debian.org/debian/pool/main/g/g...owerpc.deb 404 Not Found [IP: 130.89.148.12 80] 16:00
16:03 brrt left 16:07 leont left
robertle yeah wierd, the text says "etch and lenny" and when you follow the link you get wheezy and squeeze... 16:08
nine whatever they are 16:10
16:46 Kaiepi left 16:47 Kaiepi joined 16:48 p6bannerbot sets mode: +v Kaiepi 17:08 domidumont1 left 17:12 zakharyas left 17:19 Ven`` joined 17:20 p6bannerbot sets mode: +v Ven`` 17:25 brrt joined, p6bannerbot sets mode: +v brrt 17:30 domidumont joined 17:31 p6bannerbot sets mode: +v domidumont 17:32 japhb joined 17:33 p6bannerbot sets mode: +v japhb 17:38 brrt left 17:52 japhb left 17:54 japhb joined 17:55 p6bannerbot sets mode: +v japhb 18:11 Ven`` left
lizmat interesting: github.com/MoarVM/MoarVM/issues/1016 18:12
to me, at least :-)
18:16 Ven`` joined 18:17 p6bannerbot sets mode: +v Ven`` 18:21 japhb_ left 18:27 Ven`` left 18:36 moony_ joined, p6bannerbot sets mode: +v moony_ 18:38 Ven`` joined 18:39 p6bannerbot sets mode: +v Ven``
nine lizmat: not just you :) 18:44
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/12/10/...li-landed/ 18:56
18:57 moony_ left
nine Ok, I've now wasted my whole evening on the old Debian image being neither able to install software nor to upgrade to something newer, the openSUSE installer image just hanging when loading the initrd and ubuntu installing for more than an hour just to helpfully tell me at the very end that it didn't install a boot loader 19:07
At this point I think, people who are interested in running rakudo on big endian machines should just contribute the necessary support 19:08
samcv lizmat, that is quite interesting 19:14
19:18 Ven`` left 19:22 Ven`` joined, Ven`` left 19:45 domidumont left
robertle nine: I would like to help, but I am not sure what I can do. I have a BE machine that I can run code on, but I guess hardcore moarvm hacking is beyond me... 19:52
nine robertle: are the tests I wrote actually correct? 19:55
robertle not sure I understand, how do I tell?
I have moar g0d5f389c3 and nqp g176960303. make install with moar works of course, using that in a make test of nqp gives me gist.github.com/robertlemmen/8cbc0...05fa58d30f 20:01
apart from a line number being different by one or two, the stack trace looks just like the one of 2018.11 20:03
back in about 20mins 20:05
20:06 robertle left 20:41 robertle joined 20:42 p6bannerbot sets mode: +v robertle
nine robertle: I mean the tests in t/moar/13-writeint.t does that actually reflect how big endian works? 20:50
robertle but how can I run this without a nqp.moarvm? building that fails with the exception above... 20:59
nine You don't need to run. Just to read the source :) 21:14
But looking at switch_endian in serialization.c I appear to have understood it correctly. 21:16
Which leaves me baffled on how it still can fail in the same way
robertle please don't forget that I don't understand nqp/moar at all! how can I find out what the operands to 64 const value = (MVMuint64)GET_REG(cur_op, 4).i64; 21:25
MVMuint64 const flags = (MVMuint64)GET_REG(cur_op, 6).i64;
sorry
what the operands to writeuint actually mean, especially "flags"? interpreting your test it looks like its the size in power of two plus the endianness 21:26
but in interp.c the lowest order bit is just ignored, and size is 1 << (flags >> 1) which does not seem to match what the test suggests 21:27
but I am probaby reading this wrong...
nine flags is (size in power of two) left shifted by 2 + endianness. Endianness is 2 for big endian, 1 for little endian and 0 for native endian 21:50
robertle: something more productive would be for you to check if OP(writeuint) actually enters the if ((flags & 3) == MVM_SWITCHENDIAN) branch 21:54
robertle where is that even? I am looking at interp.c, but that appears to be the wrong place 21:55
nine interp.c:5412 21:56
robertle ah, got it now
and under which conditions would you expect that branch to be taken? in the case where flags argument is 1, 5, 9? 22:08
nine yes 22:12
so on a big endian system all the time during compilation
robertle oh, so the else branch should never be taken here? I can just put an assert in there... 22:13
nine correct
the only code that should trigger that else branch on a big endian system is 13-writeint.t 22:14
lizmat m: use nqp; dd nqp::const(BINARY_SIZE_8_BIT) # nine, is that correct ?
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
BINARY_SIZE_8_BIT used at line 1
lizmat nine: aka, are the constants as described implemented, or are we supposed to calculate that from the types we want ? 22:15
nine lizmat: I haven't added those constants yet because 1 I'm lazy and 2 constants are soooo slow in nqp
lizmat FWIW, I can live without them... as long as we describe how $flags should be constructed
nine BINARY_ENDIAN_LITTLE=1, BINARY_ENDIAN_BIG=2, BINARY_SIZE_8_BIT=0, BINARY_SIZE_16_BIT=4, BINARY_SIZE_32_BIT=8, BINARY_SIZE_64_BIT=12 22:17
lizmat nine: is there a BINARY_ENDIAN_NATIVE ? 22:20
robertle nine: I put an assert in that branch, does not trigger. I then put one in the other branch, does not trigger either. I run moar under gdb and put a breakpoint in the part before the branch, does not trigger either 22:23
are you sure writeuint is even used for this?
off to bed now 22:24
22:24 robertle left
lizmat afk& 22:25

Powered by Cro and the Raku® Programming Language.

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

Thank you!