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] |
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.