06:20 FROGGS joined 06:49 Ven joined
nebuchadnezzar FROGGS: new package uploaded this morning, waiting for build logs ;-) 07:29
FROGGS: If I understand correctly, you add libffi support in place of dynasm which should support all architecture but hurd? 07:31
FROGGS nebuchadnezzar: \o/ 07:32
nebuchadnezzar: exactly :o)
I'm about to push it right now
TEttinger woo! 07:36
JimmyZ not dynasm ,it dyncall 07:41
dalek arVM/libffi: cfdd245 | FROGGS++ | / (12 files):
support libffi besides dyncall (switchable via Configure.pl --has-libffi)

Libffi is a very portable backend for foreign function calls. So this will unblock MoarVM from reaching platforms like mips, s390x, sparc, and potentially others.
FROGGS nebuchadnezzar: I need to test this branch on windows, and I hope somebody can test it on osx... 07:42
and I need to setup mips/mipsel/s390x/sparc vms, to tweak our build system 07:43
07:54 zakharyas joined
nebuchadnezzar FROGGS: I may have some access to porter machines with my guest Debian account 08:15
FROGGS I guess there will be some build/setup.mp tweaking needed to make it work on these platforms 08:16
build/setup.pm*
nwc10 I take it that if one wants to use libffi, then one needs libffi installed already? 08:17
nebuchadnezzar FROGGS: so kfreebsd-any is OK :-D 08:18
FROGGS \o/ 08:20
nwc10: and you need to pass --has-libffi as of yet... but I'll make it the default for platforms that dyncall cannot reach atm 08:21
08:26 colomon joined 09:16 vendethiel joined
nwc10 oh gnoes. jnthn has failed to bootstrap, because he no longer has a coffee maker. 09:48
FROGGS /o\ 09:51
10:17 Ven joined 10:41 FROGGS joined 11:30 brrt joined
brrt \o 11:31
FROGGS hi brrt 11:45
JimmyZ o/ 11:46
brrt hi FROGGS, JimmyZ
FROGGS grrr, I cannot run mips or sparc because qemu either hangs at some point or segfaults 11:58
jnthn The coffee situation was solved by CEO collecting me from home and bringing me to the office, where there is coffee. 12:24
(Yes, some details omitted; it's funnier without them. :P) 12:25
nwc10 :-) 12:28
do you have a backup plan for tomorrow morning?
Or are you just going to stay up all night?
jnthn Um, no plan for tomorrow 12:29
But I have to finish some whisky tonight to prevent it going to waste :)
brrt is still a beer man 13:19
jnthn: i'm pondering how i can prevent an explosion of IR representations 13:21
the way i'm seeing it now
i need to build a machine-level IR (think: load, store, arithmetic, conversion, branching, condition flags, etc) 13:22
then i need tiles working at that level to match the IR tree to a specific piece of machine code
these should then fit into the existing jit node structure 13:23
with a single 'expression' node being a collection of tile nodes?
hmmm
that gives me a lot of entities, few of which are compatible with the old JIT 13:24
if any
nwc10 brrt: so this is not your thing? act.yapc.eu/ye2015/wiki?node=SherryTasting
brrt it'd be the first time i tasted sherry :-) 13:25
sherry is made from grapes?
i thought it was made from.... cherries
tadzik sherries :P 13:26
brrt tell me it did not make sense :-o 13:27
jnthn Sherry always felt to me like a drink that wanted to be port... :P 13:29
brrt i suppose port is also wine then? 13:30
jnthn Fortified wine
I quite like it
13:30 JimmyZ_ joined
jnthn brrt: Maybe look elsewhere for inspiration? Like, what nodes does tcc have could be worth checking 13:35
brrt: Generally though, the QAST experience is that you often don't need so many nodes.
brrt tcc is tiny, right 13:43
luajit has only a single IR, famously, but it's also quite low-level
hmmm 13:44
ok, let's start with the simplest question 13:46
what would happen if we directly use the spesh graph as IR 13:47
if i did that, then i could potentially map values to registers, do some simple register allocation 13:48
what i could not do so simply is stuff like CSE
assuming in this case that on a low level there are more commonalities for CSE to eliminate than on the moar-bytecode level 13:49
jnthn I think the spesh graph is too high level, though..
brrt yes, that is my suspicion too, but my point is figuring out why
:-)
jnthn Well, I'd take a look at the sort of things we spit out in the JIT today that are "chunks" 13:50
And also things we know we'd like to do
brrt in general, we do stuff like: load, calculate, store 13:51
jnthn Especially how we JIT things like the fast-path memory access things that attribute reads are lowered into
And how we could JIT array accesses
brrt hmmm
ok
well, the way i see it in literature, is that the operation b = a[i] is first lowered into 13:52
store(b, load(addr(a + i * sizeof(*a)))) 13:53
which is then compiled into (if possible):
mov reg(b), [reg(a)+reg(i)*scale-of(a)+offset-of(a)] 13:54
scale-a and offset-of are constants in this case :-)
jnthn Something like that lowered level sounds like what you'd want as the "JIT graph" or so... 14:00
brrt yes 14:04
the main reason, i think, to have the tile structures too, is that a tile is something that makes a single 'atomic' chunk 14:05
ultimately, it's a buffering issue 14:06
there are multiple ways to tile a graph, and you want to select the best one (fsvo best)
you do that by reducing the graph from lower to higher level nodes 14:07
given that you can 'always' take really low-level tiles, you want to 'override' them with higher-level nodes as is possible
e.g.
i could implement b = a[i] as: mul i, scale-of(a); add a, i; mov b, [a]; 14:08
but the one-opcode version is significantly more efficient
the tree reduction algorithm should then replace the lower-level operations with the single higher-level instruction 14:10
that is only possible if we haven't irreversibly committed the lower-level instructions to the stream just yet
given as we use dynasm (rather than manipulating the instruction stream itself), we need a stand-in object 14:11
does that make sense?
if we *could* buffer-and-select the instruction stream, we wouldn't need to represent the tiles seperately
another thing i kind-of want to do is register allocation 14:12
but we don't need tiles for that, we can just assign the registers in the IR for that
anyway, i'll try to sketch something out :-) then we can evaluate that 14:21
brrt afk
14:21 brrt left
timotimo looking forward to that :) 14:21
14:48 zakharyas1 joined 15:15 TEttinger joined
nwc10 FROGGS: when I origin/libffi 15:18
FROGGS: when I try building origin/libffi on both x86_64 Linux and (old) OS X, it's failing 15:19
src/core/nativecall_dyncall.c:464:47: error: ā€˜MVM_NATIVECALL_TYPE_CHARā€™ undeclared (first use in this function)
FROGGS ups
yes, I need to fix that 15:20
nwc10 :-)
how come it worked for you?
FROGGS thanks for reporting :o)
nwc10: I forgot to test the case where one does not pass --has-libffi :o)
nwc10 aha! 15:21
now, the sort of sideways question from this is, will we able to configure Travis to build both with libffi and with dyncall, and check that both still work 15:22
or at least, fail identically
FROGGS hmmm
libffi should be installable via apt on the travis boxes... 15:23
nwc10 #include <ffi.h> 15:29
on this OS X, it's in /usr/include/ffi
oh, and it's too old to have _ffi_closure_alloc and _ffi_prep_closure_loc, it seems 15:31
FROGGS user@debian-mips:~$ git clone github.com/MoarVM/MoarVM.git 15:37
Cloning into 'MoarVM'...
nwc10: okay, so we keep using dyncall there... I'm pretty fine with that
I dont want to replace dyncall on platforms where it works 15:38
japhb FROGGS: Is there a reason to keep both rather than converting to one that works everywhere? Or is the platform support of dyncall not a subset of libffi? (Or is there some other reason we want to keep dyncall around?) 15:41
FROGGS japhb: they overlap 15:42
but libffi does not work on Windows IIRC
japhb: and it is always good to have more than one choice
like with backends
dalek arVM/libffi: 30b3bbc | FROGGS++ | src/core/nativecall_dyncall.c:
unbreak dyncall build, nwc10++
 15:43
JimmyZ_ more than a way to do it
FROGGS aye
japhb Oh, fair enough. Just wanted to know if it was a "keeping options open" or "libffi is only a fallback if you can't use dyncall, because dyncall has more features" or "neither one has a complete set of platform support" or what have you. Sounds like #1 and #3 right now. :-) 15:50
FROGGS correct :o) 15:51
JimmyZ_ what ffi java use on windows 15:53
FROGGS I dont know
TEttinger JimmyZ_: I'm pretty sure OpenJDK on windows needs a microsoft toolchain, they may use non-portable APIs on windows 15:55
I know it needs a weird version of DirectX for Swing UI
FROGGS ohh, libffi states it works for Windows/Cygwin and Windows/MingW 15:56
JimmyZ_ no MSVC.. 15:57
FROGGS JimmyZ: though, there is a msvcc.sh in the tarball that cares about MSVC written by Timothy Wall [email@hidden.address] 16:00
TEttinger ironic that it's a .sh
FROGGS his names also show up in the jna or jni docs
TEttinger: probably used in a cygwin shell that does some magic
ahh, it translates gcc flags to msvc flags 16:01
JimmyZ_ andthen supports msvc?šŸ˜Š
FROGGS somehow... 16:02
It's also possible to build libffi on Windows platforms with 16:03
Microsoft's Visual C++ compiler. In this case, use the msvcc.sh
wrapper script during configuration like so:
path/to/configure CC=path/to/msvcc.sh CXX=path/to/msvcc.sh LD=link CPP="cl -nologo -EP"
nwc10 FROGGS: yes, works on my machine, and "my" machine 16:10
FROGGS :D 16:12
dalek arVM: d8c65d1 | FROGGS++ | src/6model/reprs/CPointer.c:
silence cast warning on 32 bit systems
 16:24
FROGGS nebuchadnezzar: the last commit solves the first warning shown here: qa.debian.org/bls/packages/m/moarvm.html 16:25
nebuchadnezzar: but it is not clear to me what the second means 16:26
nebuchadnezzar: what LDFLAGS need to be respected?
nebuchadnezzar FROGGS: I think it's about the hardening flag, and it happens only on one architecture 16:32
I'll see with other perl6 maintainers
FROGGS: for now I was looking at the reproductibility guide, it looks like there is something that change each time the package is build 16:33
FROGGS: for the hardening flag I'll run blhc directly on the log to have more informations 16:45
paste.debian.net/260299/ 16:49
looks like building minilua.c is missing some LDFLAGS 16:51
So, the question is why minilua.c is build on kfreebsd-amd64 and not on the other architectures? 16:53
jnthn Because our JIT only works on 64-bit, and we only need that for the JIT 17:37
I'd expect it to be built on 64-bit with Linux kernel... Also it's only a build dependency; we don't ship the minilua 17:38
FROGGS nebuchadnezzar: one thing that changes every time is src/gen/config.c 17:51
it contains an unordered hash
17:51 colomon joined
FROGGS and we record the build time I think 17:51
hmmm, there is no build date time, so that's good 17:54
I wonder if there is something else, besides the config.c 17:55
dalek arVM: 69050de | FROGGS++ | Configure.pl:
sort config.c keys to have predictable output
 18:01
FROGGS nebuchadnezzar: ^^
if I would now get the same sha1 for a release tarball, we should be fine, right? 18:02
nebuchadnezzar FROGGS: I'll try to build a package two times to see if it works 18:06
jnthn: ok, so as the amd64 is already uploaded by dod we do not have the build log, I'll check one locally 18:07
FROGGS hmmm, it still changes for me
nebuchadnezzar: I think I'll know what is going on in a minute 18:15
files that change: Makefile, src/gen/config.c, libmoar.so 18:16
I think I got it 18:22
japhb FROGGS++ nebuchadnezzar++ # Thanks for the excellent packaging work, guys! 18:28
Debian++ # High standards that make packaged products *better* 18:29
dalek arVM: 49f0c1c | FROGGS++ | Configure.pl:
sort thirdparty libs/objects etc

This is the second patch aiming a reproducable build.		 18:30
FROGGS nebuchadnezzar: I think I'm done
japhb The goal on this one is to build twice and get a bit-exact identical tarball? 18:32
Is there a plan for attacking the same problem on NQP and Rakudo? (Or do we no longer use timestamps for block IDs and such?) 18:33
nwc10 japhb: technically I think that a tarball can't be bit-exact, because it countains file timestamps. But I think that it is byte-for-byte on the file names and contents
FROGGS japhb: yes, that's the goal, and no, we can't easily achieve that for nqp/rakudo yet 18:34
japhb nwc10: Hmmm. In theory we could work around that, but understood 18:35
FROGGS: gotcha
19:17 vendethiel- joined 19:37 colomon joined 19:40 zakharyas joined
FROGGS user@debian-mips:~/MoarVM$ LD_LIBRARY_PATH=. ./moar --version 20:02
This is MoarVM version 2015.06-26-g30b3bbc
user@debian-mips:~/MoarVM$ uname -a
Linux debian-mips 3.2.0-4-4kc-malta #1 Debian 3.2.51-1 mips GNU/Linux
with --has-libffi moarvm will just build on mips without any further tweak 20:03
nebuchadnezzar FROGGS: thanks 20:18
jnthn FROGGS++ 20:32
The compiler toolchain uses timestamps in various places. 20:33
20:34 colomon joined
jnthn I can think of two of hand, of which one can possibly trivially go away 20:39
TEttinger FROGGS++, nice work fixing support for a super-obscure arch! 21:13
21:16 FROGGS_ joined 21:36 colomon joined
nebuchadnezzar TEttinger: sure FROGGS++, he does a lot to help the Debian packaging 22:20
japhb nebuchadnezzar: s/the Debian packaging// and it's still true. :-) 22:57
23:27 FROGGS joined 23:30 vendethiel joined 23:52 LLamaRider 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!