[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The relationship between SCM and scm_t_bits.

From: Paul Jarc
Subject: Re: The relationship between SCM and scm_t_bits.
Date: Tue, 04 May 2004 13:16:22 -0400
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]