Re: The relationship between SCM and scm_t_bits.

[Marius Vollmer]

address@hidden (Paul Jarc) writes:

> Marius Vollmer <address@hidden> wrote:
>> 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.
>
> What I'm saying is that (ISTM) we might be able to get maximum
> type-safety and still have zero run-time conversion cost.  Isn't that
> the ideal?

Yes, that's the ideal.  I haven't looked myself but I think that
STRICTNESS == 2 wont put SCM values into registers or something.

> But actually, SCM_DEBUG_TYPING_STRICTNESS == 1 looks like it's just as
> safe as 2 anyway.

Isn't there the added advantage with level 2 that it doesn't accept
SCM values in conditions?

>> A given location is always only accessed as one type.
>
> If that's true, then a union containing SCM and scm_t_bits would give
> us standard-conformance.

But not the best performance, I'm afraid.  Also, I'm no longer sure
that "A given location is always only accessed as one type".

>>> What do we gain here over your previous use-SCM-everywhere
>>> suggestion?
>>
>> We would have to remove SCM_CELL_WORD_LOC from the API.
>
> Is there much code outside of Guile itself using that?  I guess Guile
> itself will always need something like scm_t_bits to check type tags,
> but I wonder how useful WORD_LOC is for other code.

Since there is no OBJECT_LOC, people _have_ to use WORD_LOC (and
probably cast it to SCM* immediately).  But yes, the usage should be
pretty rare, hopefully.

>> 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.
>
> I agree.
>
>> 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.
>
> SCM_MAKINUM? :)  Or do we need the full range?  More precisely, do we
> need the full range and zero-cost conversion simultaneously?  Even
> more precisely, do we need that in the API, for code outside of Guile
> itself?

Yes, to all.  We need it to store arbitrary pointers for smobs.  When
you define a new smob type, you get to decide what to do with the
words of the smob cell: you can use them for SCMs, or for anything
else that fits into a SCM.


Well, the reason I brought this all up is that I'm adding new macros
for the use with double smobs: SCM_SMOB_DATA2 and SCM_SMOB_DATA3.
Then I have converted all code in Guile to use these macros instead of
SCM_CELL_WORD_2, etc.  But some code uses SCM_CELL_WORD_LOC, and then
I noticed that there is some kinkiness there...  I didn't feel like
rewriting the code to not use pointers, but maybe that's the cleanest
thing after all.