caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: skaller <skaller@users.sourceforge.net>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] 246 constructors?
Date: Sun, 6 May 2007 17:11:54 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0705061700070.6240@localhost> (raw)
In-Reply-To: <1178480953.4443.4.camel@rosella.wigram>



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


  parent reply	other threads:[~2007-05-06 21:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 19:49 skaller
2007-05-06 19:50 ` [Caml-list] " Jon Harrop
2007-05-06 20:20   ` skaller
2007-05-06 20:31     ` Till Varoquaux
2007-05-06 21:05       ` skaller
2007-05-06 21:11 ` Brian Hurt [this message]
2007-05-06 21:25   ` skaller
2007-05-06 22:16   ` Tom
     [not found] <20070506210912.38195BC82@yquem.inria.fr>
2007-05-07  8:21 ` Emmanuel Onzon
2007-05-07 12:29   ` skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0705061700070.6240@localhost \
    --to=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=skaller@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).