The Sinclair QL Forum

I added some comments in the code, screen base check and fixed a couple of bugs:
- declared i% as Local in 2 procedures
- memory was not deallocated at end of program

Great Andrew, you have made it!

Still cannot compile it with Turbo and I cannot understand why
Turbo parser raises no errors .
QLiberator compiles it .

Andrew wrote: Mon Dec 19, 2022 7:17 pm Still cannot compile it with Turbo and I cannot understand why
Turbo parser raises no errors .
QLiberator compiles it .

I have had a look on it and can't make heads or tails of it either. The error message I get is not listed in the manual. I fear that is an internal compiler error.

Hi everyone

Regarding the Turbo compile error, could it be the use of NEXT instead of END FOR to terminate the loop(s)?

Technically speaking NEXT is not the formal terminator for a FOR loop, so Turbo may still be scanning for the end of the structure.

martyn_hill wrote: Mon Dec 19, 2022 7:53 pm Hi everyone

Regarding the Turbo compile error, could it be the use of NEXT instead of END FOR to terminate the loop(s)?

Technically speaking NEXT is not the formal terminator for a FOR loop, so Turbo may still be scanning for the end of the structure.

No - I tried that . Turbo only raises a warning and assumes the Next is there.

OK - I finally got the program to compile with Turbo.
I still have no clue why it wasn't compiling before or why it is compiling it now.
All I did was to move the offending FOR loop into a Procedure and then call the procedure - and kaboom, it compiled it.
And yes, the Turbo compiled code is visibly faster than the QLiberated code.

I also dropped the check for screen base, suggested by Dilwyn, because it made the program not working on QL with Minerva and running QDOS
So this is the new archive and the new source code + executables
Santa_obj = code compiled with QLiberator
Santa_task = code compiled with Turbo

To get the previous version to compile, I made the following changes:

1. ensure that in-line FOR loops are not terminated with a NEXT
2. IF ... THEN FOR split into a multi-line IF
3. moved the RECHP statements up to the STOP line

At this stage, it still generated the same Turbo error. BUT... saving, then reloading the program suddenly made it compile.

So I am not entirely sure which change makes the difference, because SAVEing and reLOADing is needed for compiling to work after making changes. Which implies there was a mistokenising going on somewhere, or possibly some form of stack error which I can't see (I've only compiled with Turbo 5.09 on QPC2 5.02 to see if it is version specific).

More work needed to isolate exactly which line(s) causes the error. Probably means I'll need to LOAD, make one change, SAVE, LOAD, compile each time. Hadn't intended to spend much time on this, but once I got it to compile it suddenly became interesting in that I couldn't isolate one specific change that made it work, but I've something to go on now until boredom sets in.

Hi,

The new version looks alot better with the procedures.

In fact, the solution to Andrew's difficulty is a bit simpler than I implied my previous message - the problem lies with nested FOR loops which use NEXT to terminate the loops when used inline and there is one or more procedure. Here's an example which won't compile with Turbo (on my system at least).

100 FOR c% = 1 TO 2
110 FOR d% = 1 TO 2
120 PRINT
130 NEXT d%
140 NEXT c%
150 STOP
180 DEFine PROCedure Silly
185 REM do nothing
220 END DEFine Silly

Trying to compile this gives a compilation error at line 100 similar to what Andrew experienced.

If I now change line 140 to this (or remove the procedure), it fixes the problem:

140 END FOR c%

It looks like when the specific case of 2 or more nested FOR/NEXT loops terminated with NEXT are used inline (i.e. not in a PROC/FN) *and* there is a procedure or function, then the outermost NEXT of the nested inline FOR loops must be changed to a END FOR. It doesn't matter if the loop control variable is a float or integer. Possibly Turbo is not keeping track of nested NEXTs correctly, possibly a 1 to n versus 0 to n-1 count error within Turbo in keeping track of labels. I admit I have no idea why the nested loops compile correctly if there are no procedures, but stop compiling correctly when there is a procedure!

I quickly tried it on JS ROM in QemuLator to check it wasn't something specific to SBASIC. Apart from the fact that SuperBASIC doesn't allow integer loop variables (just change c% and d% to c and d in the example), the same problem occurs, so it is specific to Turbo, and not some form of tokenisation error in S*BASIC for example.

Not quite sure why my earlier attempts meant I had to SAVE and reLOAD the program for it to work - it's possible there's something else in there which Turbo doesn't like.