00:47 ggoebel114 joined 01:25 cognominal joined 01:26 cognominal joined 01:27 cognominal joined 01:28 cognominal joined 01:29 cognominal_ joined, cognominal__ joined 01:30 cognominal_ joined 01:31 cognominal_ joined 01:32 cognominal joined 01:33 cognominal_ joined 01:34 cognominal_ joined 01:35 cognominal joined 01:36 cognominal joined 01:37 cognominal joined 01:38 cognominal joined 01:39 cognominal joined 01:40 cognominal joined 01:41 cognominal joined 01:42 cognominal joined 01:46 cognominal joined, cognominal_ joined, cognominal joined, cognominal_ joined 01:47 cognominal joined, cognominal_ joined 01:48 cognominal_ joined 01:49 cognominal_ joined 01:50 cognominal_ joined 01:51 cognominal joined 01:52 cognominal joined 01:53 cognominal joined 01:54 cognominal joined 05:37 domidumont joined 05:41 domidumont joined 06:00 domidumont joined 06:37 brrt joined 06:48 zakharyas joined
brrt ok, i may have this One Weird Trick which makes assembly somewhat cross-platform 09:38
you know how OS X (and perhaps other BSDs) likes its C-visible symbols to be prefixed with underscore? 09:39
a 'function' is just a globally exported label in assembly
anyway, linux does not like its C-visible symbols prefixed with an underscore 09:40
with linux, i mean 'the linux linker'
and with os x, i mean 'the osx linker'
windows, idk 09:41
nothing whatever stops me from inserting two labels, one with an underscore, and one without 09:42
timotimo m) 09:46
brrt and nothing also stops me from inserting an earlier label for the windows version 09:48
timotimo if there's two labels with the same name, windows chooses the earlier one, linux chooses the later one? 09:49
brrt no, i conditionally-compile a call to the windows version or the posix version 09:53
so we get: _foo_posix, foo_posix, and foo_win32 09:54
timotimo oh, ok 09:56
how do you deal with different calling conventions "outward"?
brrt hmm, i don't even know if VSC++ accepts the same kind of assembly as gcc 09:57
or clang
this is for the stack-walking routine
so we're never calling outward
timotimo oh, ok
brrt lunch & 10:02
12:15 colomon joined 12:21 cognominal joined
lizmat liblfds.org # interesting for Moar ? 12:37
hmmm... news.ycombinator.com/item?id=11805728 12:38
12:40 brrt joined
brrt lizmat: looks interesting though 12:40
my other 2 cents: we have 99 problems, and lock-free data structures aren't necessarily a solution to a problem that i would know (now) 12:41
nwc10 github.com/MoarVM/MoarVM/issues -- 48 Open 12:42
[Coke] nwc10: www.google.com/#q=99+problems 12:43
jnthn I'm sure some RTs are Moar's fault too :P 12:44
nwc10 yes, I know it's a meme
brrt oh, lord 12:46
i had no idea we had so many GH issues
[Coke] don't look at the rakudo queue, then. :| 12:47
brrt best not 12:48
what do we think of this one: github.com/MoarVM/MoarVM/issues/372 12:49
[Coke] since moarvm also installs files, shouldn't it also be asking for moarm to install there too? 12:50
brrt probably.... 12:54
packaging o.O
[Coke] there are 5 PRs for moarvm (dating back to last september) that need to be rejected or merged. 13:03
jnthn One of them iirc is awaiting testing on 32-bit 13:04
nwc10 32-bit what? 13:06
jnthn Whatever I think 13:07
nwc10 OK. I think I had all the flags for an -m32 build in my shell history at one point...
ie x86_64 host generating x86 objects
brrt i'm going to go ahead and not think about it today 13:09
packaging, i mean
[Coke] jnthn: do we maybe want a 32bit tag? 13:11
nwc10 $ file /home/nicholas/Sandpit/moar-32/bin/moar 13:32
/home/nicholas/Sandpit/moar-32/bin/moar: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
I'd only build MoarVM 32 bit previously
re-run with MoarVM master 13:33
now building NQP with it
spectest fine, but 3 nativecall tests fail 14:08
however I was building with -funsigned-char
so whilst they *are* bugs, they may not be bugs that actually affect x86 14:09
1 is related to (seemingly) assuming that char is signed 14:29
t/04-nativecall/11-cpp.t and t/04-nativecall/13-cpp-mangling.t seem to be more general
ilmari how about x32? 15:23
which is x86_64 code with 32bit ints/longs/pointers 15:24
nwc10 I don't know if that gcc can do that 15:28
ilmari -mx32
supported on 4.9 at least
nwc10 as: unrecognized option '--x32' 15:29
"my" machine is not my machine, so I'm not root
however I'm root on my work desktop
so will try that tomorrow
ilmari installs libc6-dev-x32 and tries 15:30
configure: error: cannot run C compiled programs. 15:31
$ grep _X32_ /boot/config-$(uname -r)
CONFIG_X86_X32_DISABLED=y
oops
presumably requires a command line parameter
ilmari tries it on his sid vm instead 15:32
lots of warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15:39
nwc10 oh? do sizeof(int) and sizeof(void *) differ on x32? 15:40
ilmari it's casting pointers to/from MVMuint64
nwc10 or at least, sizeof(something we didn't expect) and sizeof(void *)
aha. oooh.
ilmari it doesn't seem to be propagating CFLAGS to the 3rdparty stuff 15:42
/usr/bin/ld: i386:x86-64 architecture of input file `3rdparty/dyncall/dyncall/libdyncall_s.a(dyncall_api.o)' is incompatible with i386:x64-32 output
nwc10 I did something like this: 15:43
Configure.pl --no-jit --prefix=/home/nicholas/Sandpit/moar-32 --cc=ccache\ /usr/local/gcc49/bin/gcc\ -Wl,-rpath=/usr/local/gcc49/lib32\ -m32\ -funsigned-char --ld=/usr/local/gcc49/bin/gcc\ -Wl,-rpath=/usr/local/gcc49/lib32\ -m32 --debug --optimize=0 --enable-jit
(that was the one with -funsigned-char)
and didn't do a CFLAGS
probably means I'm working around what is a bug 15:44
ilmari only dyncall gets it wrong 15:52
oh, git clean -xfd doesn't descend into submodules 15:59
submodules-- 16:00
git submodule foreach git clean -xfd # to the rescue 16:01
works with --cc='gcc -mx32' --ld='gcc -mx32' 16:02
Segmentation fault 16:04
Makefile:223: recipe for target 'gen/moar/stage1/nqpmo.moarvm' failed
timotimo oh my :|
ilmari fsvo "works" in "builds"
does the JIT support x32? 16:06
timotimo no
it ought to turn itself off when it sees 32bit builds
oh, that's only for mac
for linux and windows it relies on a define being set, i think? 16:07
ilmari I see there's an --enable-jit, but no --disable-jit
ah, it's --no-jit
--no-jit makes nqp build and tests mostly pass 16:10
t/nqp/060-bigint.t ..................... Failed 2/89 subtests
timotimo: how does it detect 32bit-ness? 16:11
timotimo dunno
ilmari x32 is x86-64 ISA (so extra registers and stuff) but 32bit ints/longs/pointers
timotimo we might not handle that at all
the reason we don't have x86-64 is because it has too few registers to make us happy 16:12
16:12 tomboy64 joined
tomboy64 but even when specifying --has-libffi, the logic in Configure.pl 1. tests for libff, 2. tests for dyncall, 3. tests for nativecall, all three exclusively. and during the build itself, 3rdparty/dyncall is accessed nevertheless. 16:12
this happens when i install libffi + dyncall + rm 3rdparty/dyncall 16:13
ilmari huh? you mean the reason you don't have x86-32?
timotimo sorry, yes.
geekosaur was wondering there...
ilmari well, x32 is meant to fix that, without the extra memory pressure caused by wider types 16:14
timotimo right
we'd probably have to write a second .dasc for x32
geekosaur is still a bit bemused by x32, since when x86-64 was added people asked if this would be done as well and were given fairly firm "no"s 16:15
ilmari people changing their minds in the face of evidence and experience?! shocking!
geekosaur "why would anyone want that?" (list of reasons including more registers and lower memory pressure) "but you should just run in 64 bit if you want that"
frm some segments of the open source community, yes, changing minds in the face of evidence is *very* shocking. sadly. 16:16
nwc10 clearly the folks answering "but you should just run in 64 bit if you want that" had never exposed themselves to 64 bit Solaris 16:27
very few things on Solaris were 64 bit
because, well, why burn twice as much memory (and cache) if you didn't need the address space?
(and here I'm only repeating what I was told when I asked the question)
I think PPC and PPC64 were roughly the same story
ilmari the key difference is that both ppc and sparc have decent amounts of registers in 32bit mode 16:28
nwc10 yes, exactly
tomboy64 okay, let me rephrase my initial question. are libffi and dynlib excluding each other as dependencies? 16:43
timotimo we will only build moar with a single one of them 16:44
tomboy64 alright, thanks
geekosaur yes, iirc most of them were i386 only and couldn't imagine such occurrences 17:08
on the flip side, their past experience included memory models, and I can see why someone might not want to reintroduce that insanity
(the key difference there being that you still have sane memory management with x32)
ilmari x32 is a new ABI, so they can ditch a lot of cruft 17:09
17:39 ggoebel115 joined 17:41 domidumont joined 17:52 brrt joined
brrt yeah, i'm not so fond of the whole x32 idea 17:53
tbh
18:33 TimToady joined
nine I cannot imagine there being many users of x32 anyway. 19:12
nwc10 we might have used it at NETBANX. We switched our Perl build back from 64 to 32 bits, because we figured that on the hosts running the web servers, what we had were a lot of processes wating on "the backend" (read, banks are slow at AUTHs), so what mattered more was how many we could keep in RAM easily than how fast they actually were 19:16
but back then x86 was what the toolchain offered
the hardware was all x86_64
Amex is particularly slow. But I have some confidence that that's because they are actually running decent fraud checking. 19:17
not because they are crap.
er, by banks I think I techncailyl mean "merchant aquirers" but I've probably forgotten all the right terms. 19:19
and I can't spell
20:50 brrt 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!