This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Suggestions for smob usages in an extended smob space


On 23 Oct 1998, Michael N. Livshin wrote (replying to my original post):
 
> I have a simpler idea though: the new extended smob type space should
> leave alone 1 byte (or some other predefined not-too-big amount of   
> bits).  This would mean, for 32-bit architecture, that we would have 
> 24-bit type tags, which is, IMHO, more than enough, and we'll have a 
> whole 8 bits to encode stuff.

On 24 Oct 1998, Jim Blandy wrote (replying to my original post):

> Without having thought through the details, this sounds like a good
> idea to me.  However, you'll have 2<<n repeated entries in the smob
> table.  Simply enlarging the smob range, but leaving the top eight
> bits or so for flags doesn't have this problem.

If I understand correctly, both of you suggest to leave some fixed number
of bits free for flags. Thats truly simpler than my suggestion. However,
I'm not convinced yet:

- Most smobs don't need additional flags. None of my 'personal' smob types
  does so far.

- If additional flags are needed, it should be few. I assume that no more
  than 4 bits should be used. Otherwise I would consider it a misuse: The
  data should be encoded differently.

On 24 Oct 1998, Jim Blandy wrote (replying to my original post):

> If people subtracted off the base smob number, and then masked off
> their bits, it wouldn't be necessary to align the smob numbers.

Right, that would be a simplification compared to my suggestion. We could
even go further and say that any number of smob types were to be
allocated, not only 2<<n. Assume for example, that with some smob you want
to encode three possible states. It would not be necessary to reserve two
bits, just do:

unsigned int bottom_tag = scm_newsmobs(funcs, 3); // 3 is not 3 bits, as
                                                  // suggested before, but
                                                  // it's 3 smobs. 
unsigned int top_tag = bottom_tag + 2; // It's not that simple, I know :-)

and later:

if (tag >= bottom_tag && tag <= top_tag) {
    switch (tag - bottom_tag) {
        case 0: ...
        case 1: ...
        case 2: ...
    }
}

Surprisingly, this could even be done with the current system. You simply
have to allocate the same smob three times. The only thing that has to be
taken care of is how you transform the tag number into the smob number.

Nevertheless, if you think this idea could be made into a paradigm when
using smobs, there probably should be functions for users for simpler
usage (and to warn of a misuse of the paradigm).


Thanks for your replies!


Best regards, 
Dirk Herrmann