IRC channel logs
2023-06-26.log
back to list of logs
<wingo>spk121: could be another reason to finish our own gc! <wingo>rlb: no idea regarding dynwinds; i wouldn't have thought that had anythign to do with structs. but regarding the primcall there is still the same conversion in lower-primcalls.scm, it just happens at the end of the pipeline <wingo>i made that primcall change to be able to support target-specific lowerings, i.e. to help the wasm target <wingo>which won't have wide/narrow strings <RhodiumToad>boehm-gc's logic is ... questionable, given modern compilers <rlb>wingo: well I'm guessing that it's at least questionable to use winds in say string= since it's called during struct_init which is called before dynwind_init (if the normal upstream tree is the same on that front -- haven't checked), but I side-stepped the issue anyway. <rlb>wingo: and I haven't delved yet, but regarding compile-cps.scm, I was talking about 069ed42f502c327755c10b9bc3d5f6b3bdd79202 where it looks like you dropped the wide/narrow discrimination, or is that what you just moved elsewhere? <wingo>rlb: is in module/language/cps/lower-primcalls.cm <spk121>For 64-bit Win support, the old patch just makes most long into intptr_t, which raised some concerns. So I started investigating every long in Guile to decide if it was really a long, an int64_t, size_t, intptr_t, etc. <spk121>Now, I'm thinking that maybe we change all longs to a 'long_t' and 'ulong_t' and allow a configure option to set that. <spk121>And force 64-bit Win to adapt the Linux ABI <spk121>Of course, you wouldn't get a working system unless you set sizeof(long_t) == sizeof(void *) <spk121>that's too much of a hack, I suppose.