I wanted a test following compile 1'000'000x WriteLn.

programProject1;
       begin
         WriteLn(1);
         WriteLn(2);
        // ...........
         WriteLn(1000000);
       end.

Then breaks the compiler from the following error.

$ fpc pascaltest.pas Free Pascal Compiler version 3.1.1 [2016/01/07] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling pascaltest.pas pascaltest.pas(7282,3) Fatal: Procedure too complex, it requires too many registers Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode

WinXP:

fpc pascaltest.pas

Free Pascal Compiler version 3.0.0 [2015/12/07] for i386

Copyright (c) 1993-2015 by Florian Klaempfl and others

Target OS: Win32 for i386

Compiling pascaltest.pas

Fatal: No memory left

Error: c:\lazarus\fpc\3.0.0\bin\i386-win32\ppc386.exe returned an error exitcode

Mathias wrote

I wanted a test following compile 1'000'000x WriteLn.

It's not the program that's too long, but a single procedure that's too long. If you split it up in a 1000 (or maybe even a 100) procedures, it should compile fine.

Jonas

wowowow... is there something wrong/bad with a short routine?

program Project1;
var
   loopcounter : longint;
begin
   for loopcounter := 1 to 1000000 do
     writeln(loopcounter);
end.

OTOH it's very easy to end up with enormous functions- or even an enormous main block- if machine-generating source by e.g. macro expansion. I've come across some text-processing tools which were built like this... typically via antique FORTRAN which lacked functions to get unhappy about :-)

The code is machine generated.
I wanted to test which compiler is faster, the. Of FPC or C ++ C ++ could compile the code without errors.

int main(){
   std::cout << 0 << std::endl;
   std::cout << 1 << std::endl;
....

mfg Mathias

now that you mention it, i do have a machine generated routine in one of my apps... it was much easier to write code to generate all of the individual case statements for the bit checking than to try to manually write all of them and not typo anything...

it started as tri-state for 5 sets of vars and was reduced to bi-state for those 5 sets after a huge epiphany... we ended up with 1024 case values to check instead of something over 18000...

I've come across some text-processing tools which were built like this... typically via antique FORTRAN which lacked functions to get unhappy about :-)

O:-)

I did it comparatively recently: machine-translate SNMP MIBs into Pascal. Now in practice individual functions/methods weren't that bad, but they easily could have been and having to break things up to suit an indeterminate limit would have been a right pain.

Mathias wrote

The code is machine generated. I wanted to test which compiler is faster, the. Of FPC or C ++ C ++ could compile the code without errors.

Whether or not it can be compiled is unrelated to the language of course, but to the compiler. We indeed only develop FPC for use with procedures that don't have an extreme size, because that way the compiler uses less memory and is faster. Since such massive routines are often indeed only present in case of machine-generated code, and since in that case you can usually easily adapt your generation to split up the code in multiple routines, there's not much incentive to change this (other than being able to say "yes, we can handle this").

Jonas

I've split the code, as you said.
With the factor 1000, it did not err in within about 75s compiled. The source had it about 1,000,000 rows. rows.

program test;
procedure p0;
begin
   WriteLn(0);
   WriteLn(1);
   WriteLn(2);
end;
procedure p1;
begin
   WriteLn(2);
   WriteLn(3);
   WriteLn(4);
end;
procedure p2;
begin
   WriteLn(4);
   WriteLn(5);
   WriteLn(6);
end;
begin
   p0;
   p1;
   p2;
end.

mfg Mathias

Some history:

The original Pascal compiler (Wirth in the 1970s) also had such an error message
"procedure too long"; this is a well known issue for almost all compiled languages,
and such limits hit you most of the time much earlier than physical limits or storage
limits.

The very early versions of Turbo Pascal had the problem that the generated code
had to fit in a 64 kB segment, so if you wanted to write programs of, say, more than
2000 lines, you had to break it up into several overlays. And this was another kind
of restriction, not depending on the size of individual procedures, but on the size
of the generated code of all procedures belonging to one overlay alltogether. When
designing your overlays carefully, you could write very large programs, but you had
to make sure, that calls occured only inside each overlay or from the mainline
into the overlay, but not across overlays. So the grouping of procedures into the
overlays was tricky sometimes.

Pascal/VS on the IBM mainframe threw the error message "procedure too long",
when the size of the generated code for the procedure exceeded 8 k, that was the
size covered by two base registers. That was about 500 lines only. This way you
were forced to split your procedures and functions very eary. But there was virtually
no limit on the overall size of the program.

Kind regards

Bernd

I came across some interesting stuff relating to the history of GCC. Apparently Stallman started off with a Pascal derivative ("Pastel"), but various things that the compiler did at a syntactic level (if I'm interpreting it correctly, roughly comparable with generics) meant that it had to be able to hold the entire parse tree in RAM before generating code... which exceeded the capabilities of most computers available at the time. http://www.webcitation.org/6N4WnuuZk