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] |
> > Yep. This is a problem. With a little work, we may be able to claim > > the entire upper 24 bits of the CAR for smob numbers, which would > > solve that problem. > > Do you mean the upper 16 bits, perhaps? SMOB type codes take 16 bits > as is (and I don't believe they are contiguous, but I'm not about to > read tags.h to find out). AFAIK, the only reason the upper 16 are not > used is so that SMOBs can encode a length there if they want to (and > perhaps because the SMOB table is not dynamically resized, but if that > is the case it should be fixed). SMOB types use the SCM_TYP16 macro for tests, yes, but the lower 8 bits are already devoted to just indicating that it's a smob at all. Only bits 8-15 distinguish between the various smob types. Floating- point numbers are smobs that use bits 16 and 17 to indicate the presence of the real and imaginary parts, but we could refrob that (statically reserve four consecutive, aligned smob numbers, for example).