Q_Liberator malaise

[BSJR]

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.QLibTest.zip

This prompts a new question.
As SMSQe allows for INTs in FOR loops I use that as much as possible. But I always use INT var names and don't rely on QLib to do it for me, as sometimes the FOR needs to be a Long/Float.
Does that make any difference in copyback behaviour?

BSR

[RalfR]

After changing the FOR loop to a REPeat loop the program now works correctly when compiled with QLib and Copyback enabled.

Interesting that the program started at all, I would have still suspected the runtimes.

[Artificer]

RalfR: wrote Interesting that the program started at all

I have a small number of QLIberated programs that run apparently OK with copyback. The screen copier was not one of them obviously.

[Martin_Head]

RalfR: wrote Interesting that the program started at all

I have a small number of QLIberated programs that run apparently OK with copyback. The screen copier was not one of them obviously.

Do you have AUTOF turned off in QLib

Here's a program that will list all the compiled name/variable table entries in a program. Where the original variable names are not in the name list, it will display a variable name like my decompilers varxxxx

The variable type that I tried to patch was a type '00' undefined. If I am reading the runtimes correctly, when the real name table is created, a type '00' causes the long word pointer to a variable in the name table entry to have one of the upper bits set. And if AUTOF is on, another bit is also set. But I don't yet know what happens during the FOR processing with these bits set. That's why I tried changing types '00' to type '07', a float FOR.

Something else I noticed, but I don't know if it could problems, but if it did I would expect all programs to fail. That is after entering supervisor mode, to get back to user mode, it does a move.w #$0000,sr

On a quick look at some 68060 documentation, there is an extra flag in the status register. Something about Interrupt Master. I don't know if that is al all relevant.

[tofro]

RalfR: wrote Interesting that the program started at all

I have a small number of QLIberated programs that run apparently OK with copyback. The screen copier was not one of them obviously.

On a quick look at some 68060 documentation, there is an extra flag in the status register. Something about Interrupt Master. I don't know if that is al all relevant.

Likely not. From the 68060 User Manual:

The MC68060 does not internally use the M-bit, but it is provided for system software. The MC68060 clears the M-bit of the SR when an interrupt exception is taken. Otherwise, it is up to the system software to set the M-bit and to examine it as needed

[Artificer]

Martin wrote: Do you have AUTOF turned off in QLib

Generally speaking I compile with AUTOF turned on.
Since you first mentioned AUTOF I have recompiled the screen copier(FOR loop) with AUTOF turned OFF. And the resulting screen copy is similar with lines skipped and approximately halfway through the copy starts at close to the top of the screen again.

I have downloaded your program nametable_bas and will run it later and let you know the results.

[Martin_Head]

I have spent the afternoon trying to comment all the FOR stuff in the QLib runtimes. I can't be sure I have got everything right though.

I don't like the look of these set bits that end up in an address register that accesses the variables area. It must rely on the memory wrapping around. But I don't know if that would upset things only when using the cache.

search the code for 'code 9e', 'code a4', and 'autof' to see the bit setting and and checking.

I don't know if any one with a Q60 wants to try patching the FOR stuff, to disable the integer FOR. I don't mind supplying what I done with the runtimes, if someone wants to have a go.

[tofro]

I don't like the look of these set bits that end up in an address register that accesses the variables area. It must rely on the memory wrapping around. But I don't know if that would upset things only when using the cache.

Of course that is a serious misuse of the upper address bits. But it has nothing to do with the Q60 problems - It would already be a problem on an '020, like its emulated on QPC, for example.

[Peter]

I don't like the look of these set bits that end up in an address register that accesses the variables area. It must rely on the memory wrapping around. But I don't know if that would upset things only when using the cache.

Of course that is a serious misuse of the upper address bits. But it has nothing to do with the Q60 problems - It would already be a problem on an '020, like its emulated on QPC, for example.

No, it would not be a problem on a 68020. How should it? The 68020 does not even have a data cache at all. Every access is external and wraps around.

[Andrew]

I might be totally wrong here, so please don't shoot!
Yesterday I was checking some old QL programs and I noticed that the program QL3D by Mark Swift includes a toolkit named SMSQCACH_cde with the description "Q40/Q60 processor cache BASIC toolkit 1.00"
The keywords included in the toolkit are:
DCACHE_ON, DCACHE_OFF, ICACHE_ON, ICACHE_OFF, COPYBACK, WRITETHROUGH, SERIALIZED

If this toolkit allows to turn on and off the cache then it might be used to write a test program that enables the cache only for specific parts of the code, and by doing this, to narrow down on specific offending comands that are not correctly compiled by QLiberator.