[racket-dev] stypes.h + 3M woes

At Mon, 6 May 2013 11:58:13 -0400, Jon Zeppieri wrote:
> On Mon, May 6, 2013 at 8:08 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >
> > If you're modifying "stypes.h", though, "public" is not relevant. You
> > should be able to add lots of new types to "stypes.h" without reaching
> > 512 or otherwise running into GC limits, though you do need to
> > registers traversal functions with the GC for the new type tags.
> 
> 
> Right, but I was trying to add a new type with the explicit value of
> 512. That's where I ran into trouble with the fixup_table and
> mark_table.
> 
> >
> > Maybe you can say more about what you're trying to do overall? I think
> > I'm probably giving you incomplete advice here, but I'm not sure which
> > of the various implementation details (type tags having GC traversal
> > procedures, type-tag names, hashing, versioning) are relevant for your
> > task.
> 
> 
> I was looking into what it would take to add immediately represented
> types, other than fixnums, to racket. The eventual goal is to
> represent characters in the (Scheme_Object *) word itself. The code
> point would occupy the upper N-1 bytes of the word, and the least
> significant byte would contain a type tag. Since fixnums have a 1 in
> the least significant bit, and pointers have #b00 in their least
> significant bits, the tag would have to end with #b10.
> 
> First, I thought about reserving the first 256 type tags for
> immediates (which would be sparsely populated, since, again, they need
> to end in #b10). Then I realized that the order of groups of tags in
> stypes.h is significant. Possibly the order could be reversed, to put
> the internal objects last, rather than first. But since I'm trying to
> change as little as possible, my next thought was to shift the raw tag
> (the least significant byte of the word) 8 bits to the left. So, the
> first valid immediate tag would then be 512. (For type-specific
> predicates, the shift wouldn't be necessary; CHARP could be defined as
> ((obj) & 0xff == 2), for example, but the generic SCHEME_TYPE macro
> would need to do a bit more work.)
> 
> So, I was trying to move scheme_char_type to the end of the list, with
> an explicit value of 512. The first step was just to change the type
> tag. Then I could try to change the actual representation.

Ok. I guess all you need to do for now is change `NUMBER_OF_TAGS' in
"newgc.c" to a large enough value.