[Feature Request]Add Large Procedure for FPC trunk as a new feature lazarus / 64-FPC development ---------------------------------------------------------------------- TYDQ · 2026-03-06 07:27 These days I am coding a assembler for Arm Architecture 64 bit, But I meet this error when I try to compile this program as a test for this program: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uniasinfo.pas(49580,35) Error: Procedure too complex, it requires too many registersThe Error Occurs in a Simple Line: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unias_param_type_reset(TempParamTypeList.ParamType,12);     TempParamTypeList.ParamType[0].TotalBit:=5;#Where the error occurs.   TempParamTypeList.ParamType[0].ValueIndex:=0;I don't what procedure can be checked as a large procedure,but 50 thousand line does not large in a medium-size program. All attachments must be downloaded and unzipped to merge in one folder to test. So can we have update fpc for more large and complex procedure? ---------------------------------------------------------------------- H₂SO₄ · 2026-03-06 09:18 Quote from: TYDQ on March 06, 2026, 08:27:31 am50 thousand line does not large in a medium-size program Speak for yourself ---------------------------------------------------------------------- marcov · 2026-03-06 09:23 Unlikely to happen, the limitation is the number of virtual registers used in the procedure by the register allocator, and increasing that has negative performance considerations (slower compilation for everybody, to fix essentially very few usecases, most of which are at least partially auto-generated). This has come up before, and the bugs are usually closed with "Simplify or split up your procedures." and the above rationale. ---------------------------------------------------------------------- MarkMLl · 2026-03-06 10:08 Quote from: Khrys on March 06, 2026, 10:18:12 amQuote from: TYDQ on March 06, 2026, 08:27:31 am50 thousand line does not large in a medium-size program Speak for yourself  Leaving aside for the moment consideration of whether the size of the procedure is the actual cause of the problem. I've seen similarly-sized "flat code" generated by macro-based programming systems, usually in what would now be called "retrocomputing" contexts. The result was typically processed by a FORTRAN compiler, but gave anything else problems. I've similarly seen programming systems where each line of (what appeared to be) high-level code was processed in a way in which resulted in an intermediate representation which would later be stuffed into memory, rather like a specialist assembler. I can accept that something behaving as a specialist assembler might emit an intermediate representation which wasn't amenable to being broken up into procedures. In any other context, doctrine would have it that 50kloc for a procedure is grossly excessive. I suggest trying something like changing Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program frbl; procedure guiyg; var  ... begin  line1;...  line50kend; begin  guiygend.  into Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program frbl; procedure guiyg; var  ...   procedure guiyg1;  begin    line1;...  end;   procedure guiyg1000;  begin    line1000;...  end;... begin  guiyg1;  guiyg1000;...end; begin  guiygend.  That obviously has excessive use of up-scope variable access, but should work (subject to to any comments from Marco et al.) if the problem is /solely/ procedure size. That's not to say that it's particularly good style. MarkMLl ---------------------------------------------------------------------- TYDQ · 2026-03-06 12:32 Quote from: marcov on March 06, 2026, 10:23:31 amUnlikely to happen, the limitation is the number of virtual registers used in the procedure by the register allocator, and increasing that has negative performance considerations (slower compilation for everybody, to fix essentially very few usecases, most of which are at least partially auto-generated). This has come up before, and the bugs are usually closed with "Simplify or split up your procedures." and the above rationale. Can you add a switch for compiler (Default is close) to increasing the virtual register?If not,why? ---------------------------------------------------------------------- TYDQ · 2026-03-06 12:38 Quote from: MarkMLl on March 06, 2026, 11:08:25 amQuote from: Khrys on March 06, 2026, 10:18:12 amQuote from: TYDQ on March 06, 2026, 08:27:31 am50 thousand line does not large in a medium-size program Speak for yourself  Leaving aside for the moment consideration of whether the size of the procedure is the actual cause of the problem. I've seen similarly-sized "flat code" generated by macro-based programming systems, usually in what would now be called "retrocomputing" contexts. The result was typically processed by a FORTRAN compiler, but gave anything else problems. I've similarly seen programming systems where each line of (what appeared to be) high-level code was processed in a way in which resulted in an intermediate representation which would later be stuffed into memory, rather like a specialist assembler. I can accept that something behaving as a specialist assembler might emit an intermediate representation which wasn't amenable to being broken up into procedures. In any other context, doctrine would have it that 50kloc for a procedure is grossly excessive. I suggest trying something like changing Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program frbl; procedure guiyg; var  ... begin  line1;...  line50kend; begin  guiygend.  into Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program frbl; procedure guiyg; var  ...   procedure guiyg1;  begin    line1;...  end;   procedure guiyg1000;  begin    line1000;...  end;... begin  guiyg1;  guiyg1000;...end; begin  guiygend.  That obviously has excessive use of up-scope variable access, but should work (subject to to any comments from Marco et al.) if the problem is /solely/ procedure size. That's not to say that it's particularly good style. MarkMLl It is not a useful method for approaching x64 assembly codes to machine code due to its assembly code is at least in the number of thousands machine code definition.Just split into six procedure does not consist consistently increasing assembly codes. ---------------------------------------------------------------------- marcov · 2026-03-06 13:10 Quote from: TYDQ on March 06, 2026, 01:32:56 pmCan you add a switch for compiler (Default is close) to increasing the virtual register?If not,why? It is in the typing, so, no it can't be done runtime. ---------------------------------------------------------------------- TYDQ · 2026-03-06 13:43 Quote from: marcov on March 06, 2026, 02:10:14 pmQuote from: TYDQ on March 06, 2026, 01:32:56 pmCan you add a switch for compiler (Default is close) to increasing the virtual register?If not,why? It is in the typing, so, no it can't be done runtime. Pardon my nonsense,what is the mean of "in the typing", does increasing the Virtual Register have other problem except slowing the compilation speed? And,Where are the Procedure too complex Error occurs in fpc source code(not the error message file,I cannot search the error in the pascal code of the FPC Source)? ---------------------------------------------------------------------- marcov · 2026-03-06 13:58 Quote from: TYDQ on March 06, 2026, 02:43:23 pmPardon my nonsense,what is the mean of "in the typing", They are constants in the types defined for the register allocator to my best knowledge. Quotedoes increasing the Virtual Register have other problem except slowing the compilation speed? Yes, memory footprint. But the more important fact is that increasing doesn't help. If you increase a limit today, another bug report with some extreme case will be filled soon after. And all the increase slow down the compiler.... QuoteAnd,Where are the Procedure too complex Error occurs in fpc source code(not the error message file,I cannot search the error in the pascal code of the FPC Source)? In the message file you can see the constant is link_f_executable_too_big.  If you search for that, you will end up in ogbase.pas ---------------------------------------------------------------------- MarkMLl · 2026-03-06 14:00 Quote from: TYDQ on March 06, 2026, 01:38:23 pmIt is not a useful method for approaching x64 assembly codes to machine code due to its assembly code is at least in the number of thousands machine code definition.Just split into six procedure does not consist consistently increasing assembly codes. In that case you're stuck with a non-working compiler. Sorry. Look, I'm not saying it's good or not. I'm saying that you could probably break your code up like that with minimal work and have something that compiled. MarkMLl ---------------------------------------------------------------------- TYDQ · 2026-03-06 14:03 Quote from: marcov on March 06, 2026, 02:58:08 pmQuote from: TYDQ on March 06, 2026, 02:43:23 pmPardon my nonsense,what is the mean of "in the typing", They are constants in the types defined for the register allocator to my best knowledge. Quotedoes increasing the Virtual Register have other problem except slowing the compilation speed? Yes, memory footprint. But the more important fact is that increasing doesn't help. QuoteAnd,Where are the Procedure too complex Error occurs in fpc source code(not the error message file,I cannot search the error in the pascal code of the FPC Source)? In the message file you can see the constant is link_f_executable_too_big.  If you search for that, you will end up in ogbase.pas Thanks a lot for your suggestions.I will look up the your advice for fpc insight.