Re: Increasing 32K PCode size limit within a function

On 14 Sep 2005 12:11:20 -0700, 4GL_Crusader <davidmurray@pricechopper.com> wrote: > > Error Received: > > Error number -4451. The size of the PCode generated from this function > has exceeded the 32K per function limit. > > Environment > 4GL 7.30 > IDS 9.30 > HP-UX 11.11 > > We utilize both the compiler and RDS environments. RDS is used > exclusively to generate the PCode needed for using the 4GL debugger > (Priceless). > > Background on problem: > We have a function that contains about 3000 lines which controls the > edits for a fairly sophisticated user data entry screen. We've ripped > everything out of the function outside of the core INPUT ARRAY ..... > END INPUT, but we're still running way too close to the 32K limit for > comfort. Once we exceed that limit, we can no longer create the PCode > file required by the debugger :*( Unfortunately, the remaining contents > within the INPUT ARRAY ..... END INPUT section don't lend themselves to > being relocated to another function. > > We're hoping that there's a way to increase the 32K PCode limit through > some type of configuation setting. Any help would be greatly > appreciated. Thanks. As others commented, that's an almighty big statement/function. I'd worry about the usability of the form. What size is the window? How many fields in it? How many of them handled by this single INPUT ARRAY statement? That's mostly for my curiosity... Dealing with the 32KB limit would require a new release of I4GL-RDS (and I4GL-ID). The new versions would have to be ready to deal with sizes that no longer fit in 16-bit signed integers. Obviously, it would be relatively simple to switch to unsigned 16-bit integers (64KB limit) - which would mean that older code could be managed by the new interpreters, and when there is nothing that goes over the 32KB limit, new code could be managed by the old interpreters (though that requires a bit more care, to be polite about it). The alternative is to create a new version of p-code with 24-bit or 32-bit unsigned integers. That would be a major undertaking indeed, and is unlikely to occur - actually, the signed to unsigned switch is fairly unlikely to occur either, but you've got a better chance of making a business case for that than for a more major rewrite. Don't hold your breath, though. Realistically, you should assume the 32KB limit is hard and can't be removed. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/ sending to informix-list