Recent

Author Topic: 'procedure too complex' error message: how to increase 'virtual registers' limit  (Read 11212 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Thank you both for the answers. So I understand that I need to split the procedure.

Please don't conclude too fast, Thaddy, that it is some kind of 'spaghetti code'. I owe an explanation. It is code generated by some Lz code. Code generators, i.e. some kind of IA-programming, have many advantages: no syntax error, clean structure, fast re-writing, ...

Good, so fixing so that they generate shorter sequences should be easy.

Quote
I think this sort of code generators will be more commonly used in the future, since they entail an enormous gain of time. But these code generators are capable of writing large, and even huge portions of code. So I suggest that our compilers take into account these capabilites and adapt the limits accordingly.

This has been discussed several times already, the problem is that even if the limit is stretched, people will merely generate more code and hit the next limit.

But having bitfields dynamically allocated, or preallocate extra large has performance penalties in the compiler for _each_ compilation.

It is a matter of balancing, and already quite some time ago it was decided that the current limits are never (till now) hit with normal code, and any limit will be hit sooner or later by codegenerators.

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
I look at it from a bit more fundamental point of view:
If you do use code-generators in a given language, the generated code should be such that it is within the constraints of that given language,
A code-generator that has the capability to exceed those constraints is a badly written code-generator.

Just like for all code, you should write tests for a code-generator to ensure it can cope with everything you throw at it.

Note that the constraints of the compiler are mostly documented, but hard to find and not all in one place.
In the case of OP I gave already some pointers on how to mitigate some of those constraints.

As OP states, a code-generator can help to write huge parts of correct code or even whole programs.
If OP does not take into account the constraints of the language and the compiler the code-generator is useless:
Generated code is often harder to maintain than human written code because it trades off readability in many cases.
« Last Edit: January 23, 2017, 07:37:08 am by Thaddy »
Specialize a type, not a var.

Sibylla

  • New Member
  • *
  • Posts: 13
To begin with, thanks Thaddy for the 2 solutions proposed:
- the splitting solution does the job
- the procedural-dictionary solution: I will implement it along the lines you suggest. It is much promising, especially for speed. Interestingly, I shall implement it with the code-generator. I wonder how many people would bother in such a case with writing by hand the relevant code ? But with the help of the code-generator, it is an easy task.

You are right, both, when you say that we must accomodate with the compilers constraints, and that some balance between different goals must be found. What I wanted to point out is that with the help of meta-code, i.e. code generators, we are able to produce much larger portions of code, and that we will more frequently reach those limits.

By the way, I was wondering if some code-generator couldn't be usefully integrated within Lz code editor. A simplified version writes for example a case structure, from the items list pasted in a listbox. It seems such feature would be consistent with the RAD nature of Lz.

mangakissa

  • Hero Member
  • *****
  • Posts: 1131
There are two programs I use as generator: WSDL import and XML binding. The last one is a lazy thing of me. It's not difficult to read the nodes from XML, but the importer is object orientated and works a lot easier.
The WSDL is more complex. I used it often, because it's also object orientated and it creates a XML without thinking of the structure. Last time I had to create a file by myself with indy, because the importer failed. I noticed it's a lot of work and you have to think about a lot things (dependencies, ect...) but learned a lot.

Sure, a generator helps, but is it functional (like the case example above)? It can always better. If you create your code manually, read it again later, you see it can be much more efficient and modify it with less code. Delphi has a refactoring tool, the extracted procedure / function is not always functional (3 out of 5).
Lazarus 2.06 (64b) / FPC 3.0.4 / Windows 10
stucked on Delphi 10.3.1

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Well, I use a lot of custom grammars and therefor use quite a lot of compiler generators like coco/R and Gold.
A prime example for such is a generator that generates business objects from SQL.
Specialize a type, not a var.

mangakissa

  • Hero Member
  • *****
  • Posts: 1131
A prime example for such is a generator that generates business objects from SQL.
Is it a freeware tool or an own created?
Lazarus 2.06 (64b) / FPC 3.0.4 / Windows 10
stucked on Delphi 10.3.1

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
You mean the SQL business objects generator? I wrote it, but it is owned by my former employer, highly specific - not much use outside of stock broker territory  and tied in to a bigger framework - and not open source.
If you mean CoCo/R or Gold parser? these are open source.

BTW: That is not very difficult to do for a university degree engineer: you generate a class based on the layout - not the data - of a result set. But it has almost endless possibilities, close to C#'s LINQ. A second year student should be able to do that.
« Last Edit: January 24, 2017, 01:54:44 pm by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018