Search
Tuesday, 21st of November 2017, 16:18:03 UTC
16:32:38
beach
And I still don't get the argument that you either need conservative stack scanning, or more registers so that you can dedicate some to immediate data and some to pointers.
16:34:42
stassats`
you don't need more registers
16:34:59
stassats`
but you can't have conservative registers and conservative stack because the registers are saved on the stack
16:35:27
stassats`
you either have everything precise or everything conservative
16:35:35
stassats`
where everything is stack/registers
16:36:02
stassats`
you can use as much as the eight registers x86 provides
16:37:05
beach
And the 16 that AMD64 provides.
16:37:49
stassats`
but if you are interfacing with C++ and want seamless gc, you'll end up using conservative gc
16:38:20
stassats`
and precise gc requires a precise register map (static or dynamic)
16:38:25
stassats`
i don't think llvm allows for that
16:38:37
beach
I am willing to believe that.
16:40:18
stassats`
what more registers allow -- not needing a dynamic register map, using two stacks, one tagged one untagged
16:40:38
stassats`
each stack needs at least two registers, so, four registers are always wired
16:44:30
beach
But that idea won't work if C++ interoperability is needed, right?
16:46:05
Bike
drmeister: how does one turn on debugging during build again? so that i can see arguments in a backtrace, i mean
16:49:09
drmeister
Bike: In cclasp it should use DECLAIM. Hang on for bclasp...
16:50:19
drmeister
In bclasp set core::*debug-bclasp* to T in src/lisp/kernel/init.lsp to turn it on globally.
16:50:42
drmeister
Yeah - right - I'm forgetting.
16:51:02
drmeister
# cfg.define("DEBUG_BCLASP_LISP",1) # Generate debugging frames for all bclasp code - like declaim
16:51:27
Bike
and i have to clear fasls, right.
16:52:55
stassats`
beach: not necessarily, but i don't really know how the gc handles c++
Wednesday, 22nd of November 2017, 4:18:03 UTC