The Sinclair QL Forum

Thank you, Martin! I was hoping that someone would be able to add some more context around those snippets of code.

Martin_Head wrote: Fri Mar 28, 2025 11:42 am I am currently going through QLib_run_asm trying to add comments

This is what I have for these areas

Involves FOR loops.


I am mostly working on the initialisation stuff at the moment. Not really looked into the actual running of the compiled program yet.

Interesting, the common factor here seems to be FOR loops. That could certainly explain why quite a few programs seem to break with seemingly no rhyme or reason. I hadn't heard of AUTOF before, but I also haven't really done much with Q_Liberator (even less than I have with Turbo, both of these are rabbit holes I keep meaning to explore in more detail...), so I went looking in the manual.

To quote the Q_Liberator manual:

The SuperBASIC interpreter insists that the control variable of a FOR...END FOR
loop be floating point. Release 3.2 supports two methods for speeding up compiled
programs by allowing integer FOR variables.

Interesting. Perhaps the potential FOR/AUTOF related upper address bit shenanigans only affect programs compiled with Q_Liberator 3.2 or newer? That may explain why various programs seem unaffected...

Continuing further into the manual...

The first method is suitable for most programs and is achieved via a new option,
AUTO ( -AUTOF if using in the command line interface). This instructs the runtime
system to treat any FOR variable as an integer if the start, end and step are all
integer quantities. If the same variable is later used in a floating point FOR loop,
then the runtime system alters its type to a float automatically. Q_Liberator can do
this because it knows a variable's type at runtime, a prerequisite for a full
implementation of the language.

Huh. Perhaps at least one of the bits serves a purpose to indicate that the index variable is integer, for the sake of AUTOF? Crude but "easy" way to tag the type of the variable if you're using a pointer to reference it in the first place... (not sure if they are, just speculating a bit)

Selecting the AUTO option can greatly speed up many programs, particularly if the
FOR variable is used as an array index, but there is one drawback which may be
encountered. If such a FOR variable is currently an integer and used as a
parameter to an INPUT statement, then INPUT won't let you enter a floating point
number into the variable. INPUT does not know that the variable's type is
changeable. You can get round this easily by INPUTing to another float variable,
then assigning it to the FOR variable. This will change the type to a float.
AUTO can also be turned on or off for any program after compilation using
the QLIB_PATCH utility.

This raises an interesting question: what happens if one uses QLIB_PATCH to disable AUTOF on a program known to break with 040/060 caches? I could see it possibly preventing those bits from being set... obviously, it's not a real solution, but it would confirm some suspicions...

Well, using the upper bits of an address bit is not a crime, but totally valid (albeit a bit expensive, performance-wise).

Doing that and then use the address register as an effective address is, however.

We've seen proof here for the first, but not (yet) for the second.

I worked through the bit of code around L0400 yesterday. It creates the name table, and a special type entry for this integer FOR variable.

But it's not the expected $0703, the first zero is changed. I'm not quite sure how this all works, it may have to wait till I get around to looking at the actual FOR handling.

I am still looking at the initialisation stuff, a lot of the 'fake' SuperBASIC stuff is created. The BASIC system variables, the name table, the channel table, the maths stack, etc. If WINDS are on, then #0,#1, and #3 are opened.

I have noticed a few odd things, There are two or three places where certain machine code instructions are looked for in memory. Not too sure what's going on there. Unless I am misreading the code, I think one of them is looking at the start of one of the system vectors, for a movem.l xxxx instruction.

The runtime module patches the SuperBASIC name table, to replace the CALL command. I know that there used to be a bug in SuperBASIC with CALL, so that's OK. But I was thinking, what if the runtimes are included in the compiled program. Then does the compiled program still patch the SuperBASIC CALL command with it's own code? If so, then what happens when the compiled program terminates, or the job is killed. Does it leave a ticking time bomb. If CALL is used, the code for CALL may have been overwritten with something else.

Could someone with a Q60 test the attached program with the cache turned on.

It's a patched copy of the Qdock executable, and will need to be unzipped in a QL environment.

You will need the rest of Qdock installed first.

What I have tried to do, is to convert any integer FOR control variables to floats. Which seem to be involved in the bit setting we have seen going on.

It also turns off AUTOF, if it is turned on. I don't know if this is necessary.

The patched program still seems to work OK in QPC2, But I don't know if I have caused any hidden problems.

I have included the patch program which should work with any QLIB compiled program, providing the Qdock program works.

Hi Martin,

Sadly the patched version of the qdock programs does not run on my Q60 with the copyback caches turned on. I have tried it with both smsq/e 3.41 and 3.42. THe errors it poduces are similar to the errors with the unpatched versions of qdock : varied QLib error messages, a locked window and occassionally a spectacular crash.

Artificer wrote: Sun Apr 06, 2025 12:49 pm Hi Martin,

Sadly the patched version of the qdock programs does not run on my Q60 with the copyback caches turned on. I have tried it with both smsq/e 3.41 and 3.42. THe errors it poduces are similar to the errors with the unpatched versions of qdock : varied QLib error messages, a locked window and occassionally a spectacular crash.

Thanks for that. It looks like that idea can be scrubbed.

I had thought of trying to add extra system information to the QLib error screen. But if you get varied error messages and system crashes, it sounds like general system corruption is happening, so any extra system messages may be unhelpful.

When you have programs that fail (not Qdock as it does not do anything obvious when started), Does the program seem to start, like draw any windows. Or does it crash immediately? I'm wondering if something is going wrong during initialisation, or after the compiled SuperBASIC starts.

If the compiled SuperBASIC starts, I suppose you could patch the compiled SuperBASIC to do something like, display a message, or trigger an error like 'divide by zero' and work along the program by trial and error until you hit a problem area.

I may try ripping Qdock apart and see what I can do, but I'm concentrating on commenting the runtimes at the moment, and I don't want to sidetrack myself too much.

Martin_Head wrote: Mon Apr 07, 2025 10:20 amWhen you have programs that fail (not Qdock as it does not do anything obvious when started), Does the program seem to start, like draw any windows. Or does it crash immediately? I'm wondering if something is going wrong during initialisation, or after the compiled SuperBASIC starts.

Peter has tried it with my Editor (S_Edit, no PE program) on Q60 with copyback enabled. The program was started without loaded/linked Runtimes.

The program doesn't open any windows but the job remains. The program also does not not complain the missing runtimes. The program had to be terminated with RJOB.

RalfR wrote: Mon Apr 07, 2025 10:33 am The program doesn't open any windows but the job remains. The program also does not not complain the missing runtimes. The program had to be terminated with RJOB.

That's interesting. I can't quite remember off hand, but I think the job looks to see if the runtimes are in the program, if not it then looks to see if they are installed in the system, if not, it then complains.

I'm not sure if the address of the system runtimes are stored in the system variables, or the job 0 BASIC variables area. The SMSQ/E manuals don't seem to say.

Hi Martin,

Although your patch program did not work, here is something that indicates that FOR loop variables are at least part of the incompatibility of QLib with copyback. I have a small program to copy the screen to a pic file. The program does not copy the screen correctly when compiled and with copyback enabled. It uses a FOR loop to step through the screen addresses. After changing the FOR loop to a REPeat loop the program now works correctly when compiled with QLib and Copyback enabled.
Attached is a zip file with the original sbasic program and screen shots showing the different outputs.
ScrdumpA_pic is with the REPeat loop and compiled plus copyback
ScrdumpB_pic is with the FOR loop and compiled plus copyback
ScrdumpV is with the FOR loop but executed as SBASIC plus copyback.

Artificer wrote: Wed Apr 09, 2025 10:20 pm The program does not copy the screen correctly when compiled and with copyback enabled. It uses a FOR loop to step through the screen addresses. After changing the FOR loop to a REPeat loop the program now works correctly when compiled with QLib and Copyback enabled.

Very interesting... and crazy.