[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: |
Marius Vollmer |
Subject: |
Re: The relationship between SCM and scm_t_bits. |
Date: |
Wed, 05 May 2004 12:00:34 +0200 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) |
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.
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