On Mon, 7 May 2007, skaller wrote:

> I just got this message:
>
> File "dyp_parse.ml", line 492, characters 5-19461:
> Too many non-constant constructors -- maximum is 246 non-constant
> constructors
>
> Really???
>
> (The file is generated by dypgen, it has a constructor for
> every terminal and non-terminal in the Felix grammar)
>
> At least on a 64 bit machine this is a sad restriction:
> any chance of a two byte code here?

The problem is that this is comming out of the tag word.  The current 
structure is:
 	8 bits for the tag information
 	2 bits for the GC color information
 	n-10 bits for the size of the block
where n is the number of bits in a word.

The 246 limitation comes from the 256 possible tag values minus 10 
"special" tag values for various objects that need to be handled special 
by the GC (objects that don't need to be scanned for pointers, like floats 
and strings, closures, objects, lazy thunks, etc.).

Unfortunately, this bumps right into the other favorite thread: the 2M 
limitation on arrays.  The maximum size of an array is the maximum size of 
a block- and the more bits that are given over to tag bits, the fewer bits 
there are for block size, so the smaller arrays can be.

I think a better solution, although I have no idea how difficult it'd be 
to implement, would be "large tag blocks".  For blocks with large tag 
values (say, >245), the tag value in the tag word would be the special 
"large tag" tag (say, value 246), and the last word of the block would be 
the "large" tag value.  I say last, as this means you can still get the 
nth word of a block without needing to special case large blocks.  This 
would allow a full word to be used for tag values (giving way more than 
enough tag values), and wouldn't change either memory usage or code for 
blocks with small tag values.

Brian