IRC channel logs
2023-06-30.log
back to list of logs
<spk121>ok, I've run about of ability to care about fixing Guile on Windows with threads & JIT, for now. I spent a few weeks playing with it. JIT works on 32-bit but not 64. I don't know why BDW-GC and winpthreads hate one another. <spk121>but the positive is that I can get Github's CI to build Guile on Ubuntu, Mac, and 6 different varieties of Windows builds. Should be able to add FreeBSD, too. <spk121>I'm down to 43 test failures on MinGW in my own tree. So I'll clean that up and then update with wip-mingw branch on Savannah <rlb>spk121: so no idea if it's related, and don't know if you saw it, but while toying with adding/adjusting the string-related intrinsics wingo suggested, I noticed that in the jit size_t is uint32_t, and wondered why. Or maybe that's what you've been trying to deal with? <rlb>i.e. either guile means uint32_t ranged value when it say size_t, or maybe we have a problem? <rlb>(or maybe I'm just misunderstanding...) <spk121>rlb: I would not be surprise if the problem is in there somewhere, for JIT anyway. The huge patch that Janneke started and that has been bouncing around for a year is all about dealing with platform difference between unsigned long and uintptr_t. <spk121>for common 32-bit systems long and uintptr_t is 4 and 4. For 64-bit linux/BSD it is 8 and 8. And for 64-bit Windows it is 4 and 8 <spk121>rlb: is there a specific function in jit.c that has the uint32_t / size_t confusion? <rlb>Assuming my very preliminary understanding of anything in jit is correct, see the *_sz_* functions -- they use uint32_t, but on 64-bit linus, size_t will or course be 64-bit. <rlb>Which is why I assume I'm misunderstanding something. <spk121>rlb: Yeah, I guess that on a 32-bit platform, you'd expect the _sz funcs to operate like the SIZEOF_UINTPTR < 8 versions of the _u32 operands, and on a 64-bit platform, you'd expect the _sz funcs to match the SIZEOF_UINTPTR >= 8 versions of the _u64 operands <spk121>but does the JIT's _sz need to be equal to the platform's size_t? Or is the VM's sz and the platforms size_t different things altogether <rlb>Right, that's part of what I was wondering/asking earlier. <rlb>I'll try to spend a bit more time understanding things, to see if I can figure out the right way to deal with string-set!/ref there on my own, but barring a timely resolution, I'll probably switch to see if I can just drop all the compiler optimizations there for now so I can finish up and propose the utf-8 work. i.e. come back to rework the optimizations. <rlb>(Have some days coming up where I can work on guile, and I'd prefer to spend it on the rest of the conversion, rather than learning the vm/jit -- would be happy to learn that too, just possibly not first, if feasible.) <rlb>(OK, now I see what's going on a bit better (and yes I did misunderstand, I think). i.e. some of those uint32_t types are the value storage location indexes, not at all related to the values themselves.) <wingo>uint32 is used to represent storage location, not size_t itself <rlb>wingo: I think I'm nearly there, but would I then comment out or remove for now the primcall converters? <rlb>wingo: and it looks like we're using u64 in places for u32 i.e. SP_REF_U64 for a u32 arg? If that's right, would I do the same thing for a return value? <rlb>Or could/should I add as_u32, etc. <rlb>(somewhat similar question applies to the jit, i.e. wrt handling u32) <rlb>One arrangement bootstrapped and built fine, but failed (only) a few strings tests, another landed me with "Multiple differing values and no meet procedure defined u64 scm", which I haven't tracked down yet. <RhodiumToad>rlb: SP_* is for accessing stack slots, no? so those would probably be u64 even when dealing with u32 vals <RhodiumToad>ACTION guessing a bit, has poked into the jit enough to debug some stuff but not much more than that <rlb>Hmm, and I wonder if the error is because I *also* need a scm->u32 intrinsic -- didn't quite register before, if so. <rlb>wingo: I suppose that's one of my main questions now, where do we actually want/need a u32 value for the string-ref result as compared to just using a u64. I think I see how to create u32 set/get variants in the vm and jit if we need them, but didn't know if we wanted them.