Stack size limit for If/Then statements?

[SMcNeill]

@BPlus: Yes I did lol. It was all fun and games after a few thousand lines, but about the 10,000 or 20,000 lines, things got serious. I'm glad that I didn't have to edit it after it was made.

@KernelPanic: Yes. It was a matter of running out of memory.

@SMcNeill: "What you have isn't expandable or substainable. You really need to go back to the drawing board and find a better way to automate this process."
--> I think I will have to, because if I hit the limit at 8GB, I'll start disk thrashing from there on out. I see no other choice but to do swapping and even with the SSD to mitigate this, with virtual memory the drive will be thrashing either way.

@SMcNeill: "Where are you getting the idea that STACK SIZE has *anything* at all to do with this program?? It uses no GOTO, no GOSUB. It has no RETURN statements. There's no RECURSIVE FUNCTION calls. There's *NO USE OF STACK* here at all."
--> For reference: https://communities.actian.com/s/article...Stack-Size

Look at your own article:

The two operations applicable to all stacks are:-

Push - Data items are placed at the location pointed to by the stack pointer, and the address in the stack pointer is adjusted by the size of the data item.
Pull or Pop - Data at the current location pointed to by the stack pointer is removed, and the stack pointer is adjusted by the size of the data item.

Now, where are you pushing any data onto a stack pointer? Where are you pulling or popping data from a stack pointer?


The way a stack works is like so:


GOSUB FOO >--- this now pushes the location of where this GOSUB is located in memory onto the stack.


RETURN >--- this now pops up back to that location and removes that entry off the stack.

---

IF x = 1 THEN whatever..... <-- Now, where the program making a leap that it has to return back from here? Where is that jump, that we need to put anything onto the stack??

IF statements don't add to the stack. Those are generally added to via GOSUB, CALL, or recursive routines.

Your program, as you've shared it, has *nothing* to do with stack space.


For reference to illustrate what the issue is for you, let's look at ONE line of code and translate it via QB64PE.

This is the QB64PE code:

Code: (Select All)

If x$ = Chr$(0) + Chr$(1) Then g$ = "foo": Put #1, , g$: g$ = ""

And this is how it gets translated:

Code: (Select All)

S_1:;
if ((qbs_cleanup(qbs_tmp_base,qbs_equal(__STRING_X,(qbs_add(func_chr( 0 ),func_chr( 1 ))))))||new_error){
if(qbevent){evnt(1);if(r)goto S_1;}
do{
qbs_set(__STRING_G,qbs_new_txt_len("foo",3));
qbs_cleanup(qbs_tmp_base,0);
if(!qbevent)break;evnt(1);}while(r);
do{
sub_put2( 1 ,NULL,byte_element((uint64)__STRING_G->chr,__STRING_G->len,byte_element_1),0);
qbs_cleanup(qbs_tmp_base,0);
if(!qbevent)break;evnt(1);}while(r);
do{
qbs_set(__STRING_G,qbs_new_txt_len("",0));
qbs_cleanup(qbs_tmp_base,0);
if(!qbevent)break;evnt(1);}while(r);
}

That one single line of BAS code just got translated into SIXTEEN lines of c code..

And you're wanting to work with 65,536 lines of BAS code. That's a program with over a MILLION lines of c-code which you're tossing into cpp and trying to compile.

A MILLION+ lines of c-code.... Let me stress that once again. OVER A MILLION LINES OF C CODE!!!

That takes memory to then translate those million c-lines into assembler. Then it takes more memory to link it all together. To build it. As I've mentioned, this process takes over 30 GB of RAM to run.

   

   

   

^There's some screenshots I took during the process. As you can see, it starts out with insanely high requirements and then just goes up and up and up from there.

That's not stack space that we're looking at. That's just pure RAM being used and allocated as it tries to translate a MILLION plus lines of c-code into machine code.

You've got to find a better way to do this, or else you're going to have to invest in multiple servers with petrabytes of memory to try and compile 16.7 million lines of BAS code (300 million lines of c-code....). I'm certainly not rich enough to do so, but I wish you the best of luck if you are. I'd love to see a picture of the machine which you build which can run and compile such a massive program!