Re: CUP/LEX has limitations

Scott Nicol <>
26 Jun 2005 12:34:28 -0400

          From comp.compilers

Related articles
CUP/LEX has limitations (Sharma, Girish \(Girish\)) (2005-06-23)
Re: CUP/LEX has limitations (Scott Nicol) (2005-06-24)
Re: CUP/LEX has limitations (Joel Jones) (2005-06-26)
Re: CUP/LEX has limitations (Scott Nicol) (2005-06-26)
Re: CUP/LEX has limitations (2005-06-30)
Re: CUP/LEX has limitations (glen herrmannsfeldt) (2005-06-30)
Re: CUP/LEX has limitations (Scott Nicol) (2005-07-02)
Re: CUP/LEX has limitations (Martin Ward) (2005-07-03)
Re: CUP/LEX has limitations (A Pietu Pohjalainen) (2005-07-22)
| List of all articles for this month |

From: Scott Nicol <>
Newsgroups: comp.compilers
Date: 26 Jun 2005 12:34:28 -0400
Organization: Compilers Central
References: 05-06-115 05-06-118 05-06-129
Keywords: Java
Posted-Date: 26 Jun 2005 12:34:28 EDT

Joel Jones wrote:
> At 9:55 AM -0400 6/24/05, Scott Nicol wrote:
>>I haven't used CUP/LEX, but I'm quite familiar with the "code too
>>large" error in Java. Java has a limit of 64k code per method (you,
>>like I, might be wondering what was being smoked when that decision
>>was made).
> The solution is to write
> strings in the source and then unpack the strings at run time.

But you've got to be careful to make the string constants less than
64k, because that's another small fixed limit in Java. Hence the use
of arrays of strings.

So assuming CUP's tables aren't the issue that caused the original
poster's problem, what's next? The reduction code. Typically the
state machine will have code that looks something like this:

if (reduction) {
switch (state) {
case 1:
// user's code for reduction 1
case 2:
// user's code for reduction 2
case 1437:
// user's code for reduction 1437

This will probably fail, because all of the user code is lumped
together in one method, pushing the method over the 64k limit. There
are a few ways to fix this. Simplest is to make your action code as
small as possible -- make each action a method call, instead of coding
the action in-line. But this can only take you so far, and you can
still run up against the 64k boundary. The next step is to split the
generated switch into multiple methods, i.e.:

if (reduction) {
if (state < 500)
else if (state < 1000)

> I have often wished that the .class file had a means of doing
> array initialization. However, given endianess and implementation
> choices for arrays, I can see that many VMs would end up not being
> able to use the initalized array "in-place" anyway.

So have the array written out in one format (pick one), and the VM can
gleefully swap bytes around in place if necessary. I like Java, but I
dislike the ridiculously small arbitrary limits placed on source code.

Scott Nicol

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.