[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
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
Re: The relationship between SCM and scm_t_bits., Marius Vollmer, 2004/05/10
Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/15
Re: The relationship between SCM and scm_t_bits., Dirk Herrmann, 2004/05/15