Galleon, will this version of QB64 be able to handle a 100,000 line program?

[Pete]

It (qb64) did great with the 26,000 line program, but before I try the next one, I'd like to know if there is enough wiggle room to make a 100,000 line program, approx 2.5 MB of source code?

Pete

[Clippy]

DO IT Pete! Fatman has already done one good thing. He has pried the "limits". I don't think it will break QB64's back!

Ted

[Galleon]

The isn't any specific reason known to me why this wouldn't work.

QB64 compiler limits are a bit arbitrary because they are simply arrays which can be adjusted very easily. Soon I will be adding REDIM _PRESERVE to QB64 and as soon as I do I will be applying it to the compiler which will mean the only limit of the QB64 compiler will be your RAM.

That said, here are the current compiler limits:
1000 UDTs
10000 constants
10000 id (includes variables, subs & functions)

I tried a silly test to see what QB64 would do with a file of 1000000 lines of the PRINT statement (just PRINT). The IDE loaded it but took forever to check it. That's 7MB of source code. The "qb64 -c print.bas" option worked fine, but it was no 'roadrunner' speed wise.

Hope this info helps.

[Dav]

Here's a program I use to generate .BAS's to test those kinds of limits.
It makes a BAS containing 10000 lines of unique variables, like T$1="0", T2$="0", etc.

The current QB64 IDE appears handle 9779 different variables before choking down and reporting
this error:

"compiler error (check for syntax errors) reference:9-6363 on line 9780"

The current QB64 does it MUCH faster than previous versions.

I have not found a line limit yet of just regular statements like PRINT.

OPEN "varitest.bas" for output as #1

for T = 1 to 10000  '9779 is current QB64 variable limit...

    a$ = "T" + LTRIM$(STR$(T)) + "$=" + CHR$(34) + "0" + CHR$(34)

    'a$ = "PRINT" '<<< use this one instead to generate a simple line

    PRINT #1, a$

NEXT
CLOSE

[Galleon]

The current QB64 IDE appears handle 9779 different variables before choking down and reporting
this error:
"compiler error (check for syntax errors) reference:9-6363 on line 9780"

It's no coincidence that it starts with a 9. ERROR 9 is "Subscript out of range". The reason it's only 9780 is because there's a lot of internal subs and functions (eg. PSET) which take up ID indexes.

[Dav]

Well 9780 is way more than I'll ever need. The new IDE is very impressive auto-indenting large programs. And it runs much snappier than previous ones for me.  I'm enjoying using it. And like others have stated, it almost feels like Qbasic.  Great work!

- Dav

[Pete]

Good stuff. I think I will get started on the conversion.

I count 750 subs.

The variables are what I have to work on next. I just made a DIM SHARED table, which combines all the shared variables of all programs. Now I have to do this:

1) Write a utility that identifies every variable in each program and then checks to see if that variable is a DIM SHARED variable that is not part of that original program.

To make that more understandable, an example of joining two programs:

REM PROGRAM A
DIM SHARED a, b, c
CALL x
PRINT c
END
SUB x
c = 5
END SUB

REM PROGRAM B
DIM SHARED a, b, z
CALL y
PRINT c
END
SUB y
c = 5
END SUB

COMBINE Both

DIM SHARED a, b, c, z
CALL x
CALL y
PRINT c
END

SUB x
c = 5
END SUB

SUB y
c = 5
END SUB

------------------

The problem is that in Program B, C is not shared and would be 0, not 5. When the DIM SHARED variables are combined, this changes, which could create bugs.

I plan to try and isolate all variables to see if any are DIM SHARED in another program and if so, change the names. If it gets to complicated, I just do global name replacements of all DIM SHARED variables so the name of the program they came from is added to the front of the variable. That would create all unique names, but a much larger DIM SHARED table. So far, I've cut the number of DIM SHARED variables (duplicate variables in other programs) from roughly 850 to 275.

Anyway, just some of the preliminary work involved before joining these programs together successfully can be accomplished.

Pete

[Clippy]

I learned a long time ago to use unique variable names inside of a SUB with non-shared variables. So you really cannot blame that on anybody but yourself. Especially non-descriptive names such as c.

Ted

[Pete]

QuickBasic would not allow enough space to pass all the variables, so doing it as you described was not an option. Also the overwhelming number of subs you would have to keep track of to make sure a variable used in many subs was actually being passed would be time consuming. SHARED variables serve an important role in complex program development.

Anyway, the variable tables I just ran show approx 6,000 independent variables, well under the 10,000 max.

Pete