Compiler error due to memory limits

[Ryster]

To FellippeHeitor.
Fellipe wrote:

DOWN
LOOP
Is this supposed to be a joke?
You write about efficiency. In DOS times, every byte was worth its weight in gold. Today in the Windows era, who pays attention to such a small thing: kilobyte or megabyte. He does not care about anyone anymore. The frequency of processors calculated in gigahertz, RAM in gigabytes. Even if the program was not effective, it will not be important for the potential user. Anyway, nobody cares how it works - it's important that it works properly. In summary, each program can be improved, changed - just why mix as something works properly in the final sense.
Thanks with help.

To pagetelegram
Chris?   Ryster!
I am afraid, saying, I was afraid to raise this topic in the Forum. The program has been developing for about 13 years. When writing a program, I did not write only for myself, but also for other users in the global sense. Users from different parts of the world use my program, and somehow nobody complains.
https: //www.qbasic.net ... I do not really understand what you mean.
Thanks for showing interest. I think that you should finish this topic - Administrator probably lost patience. Greetings.

[pagetelegram]

Ryster,

Use FreeBasic! With that compiler every byte does counts! Instead of a 1.5mb+ QB64 compile you get your old DOS sized 40kb+ compiled executable.

Just put

Code: QB64: [Select]

1. #lang "qb"
2.  

at the top of your code and compile away!


https://www.freebasic.net/

[anon1]

Maybe that'll be the final solution. Freebasic for the win.

[pagetelegram]

OP, you kind of sound a bit like me on one point I think we can relate: with your expression that "every byte was worth it's weight in gold." I could concur with that, that Moore's law has led to bloat in my opinion.

However I also concur to William Strunk's philosophy to "omit needless words," in the Elements of Style even though I maybe better at that as a writer than  as a programmer.

With programming, I'm a tad bit lazy to think about organization and making code easily understandable by others with well put remarks and variable names that make sense.

[Cobalt]

To Cobalt
Thank you for this advice. I will find one, second, third ... then several hundred or several thousand.

That is quite possible, there has been times I have found a great many lines myself. But the only way to get started is with that first step(or in this case 'line').

and remember with out code for us to look at and try to compile on our side all we can do is advise, not fix. just FYI.
Don't think that Fellippe is being rude or mean he is just doing what he can while being blind, as without something to see(the code in this case) we are all just blind. If you are hell bent against letting others see the code that is fine, just don't expect a miracle fix to suddenly spring up here. As you are the only one that is having a problem compiling at this time.

Just curious how long does it take the IDE to parse your BAS file or are you not loading it into the QB64 IDE? I am just wondering cause I once tried to include a 400k (391k to be more precise) data file into a programs source and the IDE wouldn't parse the program anymore. That was back before there was an option to turn off the syntax checking though.

[SMcNeill]

That it is not effective may be true, but it is also true that the code's syntax is correct.
As if it were Otherwise, I would never compile the code. I will not improve efficiency again. Anyway, if the code does not contain syntax errors, then it should be compileable. Otherwise, the fault lies on the compiler side. Nevertheless, thank you for your comment. Greetings.

Here's a quick little program -- only 4000 lines of code:

https://www.dropbox.com/s/1dqiyvgpcw33w4f/AplhaPrint4000.bas?dl=1


Download a copy of it.  Paste it into QB64.  It's syntax is just peachy fine.  Not a single glitch in it.

BUT....

It won't compile. 


WHY??

(For those who might not want to download the file, it's basically just a copy/paste of this one line 4000 times:

PRINT "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z" )

Go take a look at the C-output which we generate in temp/main.txt and see what it looks like...

444,023 lines of code!!

QB64 translates BAS to C, and PRINT is a monster to translate.  Each one of those lines translate into a hundred lines of c-code, and the compiler simply craps out eventually while trying to build it.

cc1plus.exe: out of memory allocating 16008 bytes

Now, the way around it is to fix the code so it doesn't have 4000 repititions of copy/pasted PRINT Statements.  The below works just fine:

Code: QB64: [Select]

1. FOR i = 1 TO 4000
2.     PRINT "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"
3. NEXT

Or change the code to PRINT "A" + "B" + "C" + "D" + "E" + "F" + ....

It translates to a whole lot fewer lines than print with semicolon as a delimiter, and prevents the issue...


And none of these limits is actually anything imposed by QB64 itself.  It's all just the compiler hitting its internal limit on something, and there's nothing we can do for you about that.

It's a choice of either rework the code  to reduce the burden on the compiler, or else find a completely different compiler and give it a shot to see if it has the same limits.  Either way, there's not much we can actually do for you about the issue.  It's not QB64 which is failing; it's the limits of the c-compiler itself which you're running into.

[Cobalt]

no kidding Steve, there are 104000 copies of these 4 lines for the 26 letter. hell does 'makefit' do?;
qbs_set(tqbs,qbs_new_txt_len("T",1));
if (new_error) GOTO skip8000;
makefit(tqbs);
qbs_print(tqbs,0);

even if you turn $CHECKING:OFF it still has the IF GOTO lines. kind of thought those would go away since they seem to be error checking lines.

though I got this error in the compile log:

cc1plus.exe: out of memory allocating 33558527 bytes

[Cobalt]

Got it to compile at 3000 lines.
and it runs.
might be able to squeak it up to about 3300 lines I think..

SURE THING, 3300 line compiled and run!

Gonna try for 3500.....
oooohhh... nope... BUT 3450 line worked!!!!
so somewhere between 3450 and 3500 lines is max printing that way.

[SMcNeill]

no kidding Steve, there are 104000 copies of these 4 lines for the 26 letter. hell does 'makefit' do?;
qbs_set(tqbs,qbs_new_txt_len("T",1));
if (new_error) GOTO skip8000;
makefit(tqbs);
qbs_print(tqbs,0);

even if you turn $CHECKING:OFF it still has the IF GOTO lines. kind of thought those would go away since they seem to be error checking lines.

though I got this error in the compile log:

cc1plus.exe: out of memory allocating 33558527 bytes

makefit is the word wrap routine which comes when you print, IIRC.

the (new_error) handles user breaks during execution, such as clicking the little red X in the top right of the program.  It’s not specifically for error detection, but user interruptions.  (Does Ctrl-C still break loops/execution?  I don’t remember what all it catches now, honestly.)

All the lines with “qbs” stand for Quick Basic Strings.  We set a temp string type to hold the constant value with qbs_set, then print it to the screen later with qbs_print...

QB64 translates everything just fine.  The c-compiler just runs out of memory before it can do its thing.

[Cobalt]

in the 32bit version I was able to compile 3450 lines of your test program, with an output exe size 7.38megs.
fails at 3500 lines so, there is probably a command line option like -bigobj (visual studio) that would allow larger file compiling, but I couldn't find anything on it. There has to be something out there cause I'm sure somebody has made a c or c++ program that consists of far more than 400000 lines out there.

[SMcNeill]

in the 32bit version I was able to compile 3450 lines of your test program, with an output exe size 7.38megs.
fails at 3500 lines so, there is probably a command line option like -bigobj (visual studio) that would allow larger file compiling, but I couldn't find anything on it. There has to be something out there cause I'm sure somebody has made a c or c++ program that consists of far more than 400000 lines out there.

It’s however c tries to optimize the code.  Run it and watch memory usage in Explorer.  It goes up, up, up, and up, until it crashes.  There may be -no-optimize flags you can set to bypass the issue, but if so, I have no clue what they are.   At around 1.6GB memory usage, the c-compiler crashes.

[Ryster]

For SMcNeill analysis.
There are 39730 in my PRINT program.
The whole has nearly 65,000 lines. Currently, the program compiles correctly. But how do I want to add about 3000 lines not necessarily all of PRINT - memory overflow error. So the PRINT function is not a problem in itself. The problem occurs when we connect PRINT in a chain with other elements.

[SMcNeill]

As others have said, without the actual code, there’s nothing much we can do to help.  My example above was to demostrate one possible issue where perfectly valid code translates but then fails to compile.  PRINT is a monster behind the scenes, and you have almost 40,000 lines using it.  I simply demonstrated where as little as 4,000 can cause the compiler to fail with the memory issue you’re experiencing.

Unless you can share the code, your only real options is to:

1) Rework to code to reduce the c-compiler memory usage, so it works.
2) Try a different compiler or optimization switches/settings to improve efficiency.
3) Try a different translator such as FREEBASIC, described above.
4) Get frustrated, scream “Screw it”, toss it in the recycle bin, and binge out on Ben’s & Jerry’s

[Ryster]

Ha, Ha. You will have to wipe your eyes with astonishment. I downloaded your file and compiled correctly. I attach the scan as proof. I did not combine anything with the code. I just have a version of QB64 and I keep it on the disk like a relic.

[SMcNeill]

It’ll compile with the QB64x64 version, as the memory ceiling is higher, but copy paste it a few times and you’ll quickly hit the same issue.  Each compiler has its limits.  Your code has caused the version you’re using to hit its.  Your only real options, I listed above.