Re: Suggestions for smob usages in an extended smob space

[mike@olan.com (Michael N. Livshin)]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> Hello!
>

[ snip ]

> long scm_newsmobs (scm_smobfuns *funs, unsigned int n);
> 
> The idea is that a range of smob tags is reserved in a way that allows
> easy extraction of the n bits from the smob tag. This can always be
> achieved by leaving some smob numbers unallocated. To clarify the idea,
> look at the following example:
> 
> long a, b, c, d;
> a = scm_newsmob(a_funs);      // assume smob tag #5 is returned. The whole
>                               // tag is used to indicate the smob type.
> b = scm_newsmobs(b_funs, 3);  // returns smob tag #8: All but the lowest 3
>                               // bits indicate the smob type. The lowest 3
>                               // bits can be used by the application to
>                               // encode additional flags. I.e. this type
>                               // uses smob tags #8 - #15.
> c = scm_newsmob(c_funs);      // returns smob tag #16
> d = scm_newsmobs(d_funs, 1);  // returns smob tag #18 (18 and 19 are used)
> 
> In practice it is not that simple, since the smob bits are probably not
> the lower bits of the tag. Thus, to extract the bits, additional masking
> and shifting is necessary. Nevertheless, for the disadvantage of leaving
> some smob slots unused, flags can easily be encoded within the smob type.
> (The disadvantage could also be avoided by offering a mechanism that
> allows to use those skipped smob types).

Indeed, not that simple.

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.

Not disagreeing with you, just that this is much simpler to implement.

[ thanks for your comments in that other thread, BTW ]

later,
mike.