Re: The relationship between SCM and scm_t_bits.

[Paul Jarc]

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?

> 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.  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.

> 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.

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?

> 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.


paul