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