Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer]

address@hidden (Paul Jarc) writes:

> Marius Vollmer <address@hidden> wrote:
>> Now, the distinction between scm_t_bits and SCM is only then practical
>> when converting between them has zero cost.  SCM_PACK and SCM_UNPACK
>> can really only be casts that reinterpret the bits.
>
> Looking at the case of SCM_DEBUG_TYPING_STRICTNESS == 2, I'd expect
> that scm_pack might be optimized away, so it would have no run-time
> cost.  (At least, the compiler has enough information to do so, and
> the C standard allows it.)  If that isn't happening already, maybe
> marking it as inline would help?

SCM_DEBUG_TYPING_STRICTNESS == 2 is not meant for production code (I
have to review it anyway, there has been a bug report about it not
working at all, I think), so when compiling with that setting, the
performance argument doesn't count.

>> Thus, scm_t_bits and SCM can be pretty much identical and we can allow
>> the casting of pointers to them, too.
>
> The C standard does not allow accessing a value through a pointer to a
> different type.  Newer versions of gcc have optimizations depending on
> that restriction included in -O2.

Yes, we are pretty much non-standard when doing this, but it is OK
when it 'just works' in practice.  The optimizations should only bite
when we access the same memory location thru to differently typed
pointers, but we would not be doing this (I think).  A given location
is always only accessed as one type.

Err.  Or so I thought.  We have

   SCM_CELL_OBJECT (x, n) === SCM_PACK (SCM_CELL_WORD (x, n))

which would cause trouble when used together with

   *(SCM_CELL_OBJECT_LOC (x, n)) === *((SCM *)(SCM_CELL_WORD_LOC (x, n)))

Well.  I'm still confused...

> You can disable those optimizations with -fno-strict-aliasing, but
> maybe those optimizations would outweigh some nonzero-cost
> conversion between scm_t_bits and SCM.  Some profiling would be
> useful.

We already aim to be -fstrict-aliasing safe: see for example
scm_double_cell in inline.h.

>> Pointers to scm_t_bits might still fail on strange platforms and we
>> might then consider removing SCM_CELL_WORD_LOC on those platforms.
>
> Better to make Guile the same on all platforms, I think, and so remove
> it on all platforms if it doesn't work on some.

Yes.

> Granted that it's useful to have both SCM and scm_t_bits, what exactly
> is the advantage in using those two types to alias the same bytes in
> memory?  What do we gain here over your previous use-SCM-everywhere
> suggestion?

We would have to remove SCM_CELL_WORD_LOC from the API.

>> But we would need a very good reason for this: using pointers the
>> way delete_some does is completely reasonable right now.
>
> Well, it's expected to be reasonable, but turns out to be not quite
> so, right?  Hence the issue.

Hmm.  The (my) reasoning goes like this: first, we only had SCM and
everything was simple.  Then we added scm_t_bits to emphasize the
opaqueness of SCM but still be able to interpret its bits.  That gave
us the possibility to use these two types for the two kinds of words
in the heap: some are interpreted as a SCM (with tag bits and
everything), some are not interpreted and can contain anything that
fits into one word.  This makes SCM a subtype of scm_t_bits: all SCM
values can be represented with a scm_t_bits, but not all scm_t_bits
values are valid SCM values.  Thus, the basic type of heap words is
scm_t_bits.

That, however, creates the issue with having pointers to SCM.


When we can only have one type of pointer (either SCM* and
scm_t_bits*), I would want to have pointers to SCM since SCM is the
type that the users works with.  That would mean that heap words are
of type SCM.

That then also means that SCM_PACK would be used to store 'invalid'
values into a SCM and can no longer be used to mark places where only
valid SCM values should appear.  Maybe we should have a new
SCM_PACK_BITS for this, or maybe not.

Damn, I can't get my head around this...  My instincts tell me to just
remove scm_t_bits from the public API completely, but that is rather
drastic, maybe for 1.10...