Andy Wingo <[email protected]> skribis: > On Tue 05 Feb 2013 23:31, [email protected] (Ludovic Courtès) writes: > >> This would be less of a problem if we had “immediate pointers” [0]. >> Would the retagging in 2.1 allow this? > > The tc3 itag allocation in wip-retagging is: > > * tc3: > * 000: A heap object with a tag word on the heap > * 001: Some other immediate > * 010: A pair > * 011: Small integer (odd) > * 100: (Unallocated tc3.) > * 101: (Unallocated tc3.) > * 110: A struct > * 111: Small integer (even) > > And SCM_IMP is: > > #define SCM_IMP(x) (1 & SCM_UNPACK (x)) > > So perhaps 101 could be an immediate pointer. Dunno. Pretty nasty > stuff!
Would be cool, I think. Maybe we should make an auction for unused tc3 tags? :-) >> (At FOSDEM, Luca Saiu rightfully noted that we could use 4-bit tags >> instead of 3-bit tags on 64-bit arches, which would give us the needed >> room here.) > > GC_malloc still returns eight-byte aligned memory hunks on 64-bit, no? Oh right: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> (use-modules (system foreign)) scheme@(guile-user)> (pointer->procedure '* (dynamic-func "GC_malloc" (dynamic-link)) (list size_t)) $2 = #<procedure 1b60ac0 (_)> scheme@(guile-user)> ,use (srfi srfi-1) scheme@(guile-user)> ,use (srfi srfi-26) scheme@(guile-user)> (unfold (cut > <> 100) (lambda (i) (logand (pointer-address ($2 (* i 2)) ) #x15)) 1+ 0) $7 = (0 0 16 0 16 0 16 0 16 0 0 0 0 0 0 0 0 16 0 0 16 0 0 16 0 0 0 0 0 0 0 0 0 16 0 16 0 16 0 16 0 0 0 0 0 0 0 0 0 0 16 0 16 0 16 0 16 0 0 0 0 0 0 0 0 16 0 16 0 16 0 16 0 0 0 0 0 0 0 0 0 16 0 16 0 16 0 16 0 0 0 0 0 0 0 0 0 16 0 16 0) --8<---------------cut here---------------end--------------->8--- If needed, we could just round up all the addresses returned. And with 16 cases, we could even put single-precision floats in a word, chars, and who knows what! The downside is that we’d have to maintain two tag systems. Ludo’.
