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
<wingo>scm
<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>There are 600 of them.
<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.