Re: CUP/LEX has limitations

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
...
break;
case 2:
// user's code for reduction 2
...
break;
...
case 1437:
// user's code for reduction 1437
...
break;
}
}


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)
reduction0to499(state);
else if (state < 1000)
reduction500to999(state);
else
reduction1000to1437(state);
}


> 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
snicol@apk.net

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