Q_Liberator malaise

[pjw]

Shouldnt we continue to discuss the topic a the Qlib cache problem on
68040/68060 CPUs? If we could manage to narrow down where the problem could
lie, it might be possible to do something. Hopefully its nothing systemic
that would require a redesign!

A pity the discussion so far got muddled with another thread. Here is the
start of the discussion for reference:

From "Compiling a SuperBasic program"
https://www.theqlforum.com/viewtopic.php?p=61115#p61115

In https://www.theqlforum.com/viewtopic.php?p=61181#p61181 Artificer did
some experiments.

Today, I tried patching 7 qliberator compiled programs this morning
with the SYSREF_task. For 3, SYSREF_task made no changes and for the
remainder it patched 2 locations and then modified other parts of the code
to be 32 bit compatible. It made not one compatible with the copyback cache
setting on my Q60. Those that it patched all reported the QLib runtime
error "FOR type error" regardless of cache setting.

Were the programs you tried to patch of the same vintage as SYSREF_task? I
dont know when that program was written as I cant find any date, but it could
be around 1990. So perhaps try to patch something compiled pre 1990, if you
havent already, and see where we go from there..

[RalfR]

Very good Per! So I repeat my general question:

As far as I remember (but I may be wrong), Liberation Software were still in their QLiberator programming process when the Qxx were launched. They have done a lot of corrections during TT's Atari phase and the Minerva phase. I wonder, if Peter have sent them details of the remaining problems (perhaps he did, I do not know), so they were able to correct them.

And if so, why didn't they do it?

[Artificer]

Per wrote : Were the programs you tried to patch of the same vintage as SYSREF_task? I
dont know when that program was written as I cant find any date

Hi,
The answer to that question is no.

My original copy of SYSREF_task is dated on the floppy from october 1995. I bought QLIB probably a year after that so my earliest programs with QLIB are from then.
The programs I tried patching were Launchpad, Qdock, Qtrans, Eddicon and KCMaster (one of my original QLib compiled), all upto date as far as I know. Dilwyn's I imagine built using easy pointer and the latter 2 with QPTR.

I doubt there is a panacea to be found with older patch programs although i have recollection of some other cache modifying software. With the source code of QLib available and extensive testing of existing programs running during copyback it might be possible to come to an understanding of when and what causes QLib to self modify and then to examine the source for a solution if it lies there. It may not.

Cheers

[Mark Swift]

Hi,

The symptoms point to self modifying code as mentioned.
The solution would be to flush the cache out to memory prior to calling the code.

You could trace the code in order to find the offending instructions. It's do-able given a bit of time.

When posting about SYSREF_task I couldn't remember what it did for QLIB.
Looking at the SYSREF_bas source it only fixes QLIB for some 32 bit issues plus some instructions that clear SR and so lose the trace bits. The 32 bit issue would only show up if running from an address bigger than 24 bits.

[Peter]

The symptoms point to self modifying code as mentioned.

Yes. But it does not seem to affect only the program start. For example, I like Dilwyn's Q-Dock. It would have been okay for me to start Q-Dock in serialized or writethrough mode, and swith to copyback cache later, so I tried that as a workaround. Failed. Not sure if other QLiberated programs are also affected by it.

[Peter]

I wonder, if Peter have sent them details of the remaining problems (perhaps he did, I do not know), so they were able to correct them.

No I did not. The problem is not specific to Q40 or Q60 at all.
It is a general issue with separate caches for code and data, affecting all 68K CPUs > 68030.
Also, I had no idea there was work in progress toward a more clean QLiberator implementation.

[Peter]

Shouldnt we continue to discuss the topic a the Qlib cache problem on 68040/68060 CPUs?

Many thanks Per, for keeping this topic alive in a specific thread. Unfortunately, I have no knowledge of QLiberator at all. And also no direct interest in using QLiberator or analysing it. My only interest is to get some fine pieces of software running on > 68030 somehow, without crippling the machine. Which would also be motivating toward an improved Q60 hardware design.

As you pointed out previously, the main (and almost only) point for QLiberator under SMSQ/E is the ability to pack the BASIC code together with any toolkits as a single unit, and to leave the machine clean once the program terminates. And probably the option for software authors like Dilwyn to keep their sourcecode undisclosed.

I wonder if the creation of a "packer" tool which accomplishes this goal without actually compiling the S*BASIC code is the faster solution.

[Derek_Stewart]

Hi

Does the same problem occurr in Turbo compiled programmes?

[Peter]

Does the same problem occurr in Turbo compiled programmes?

Not that I know. But apparently it is a problem for the respective software authors to use Turbo.

[Peter]

To underline the dimension of the malaise:

Q60/80 reduced to writethrough mode (SMSQ/E default because of QLib) = 53475 Dhrystones/s
Q60/80 with copyback cache = 102459 Dhrystones/s

When it comes to a relatively meaningful measure of CPU performance, the Dhrystone benchmark seems the best pick we have. So I think one can roughly say, that a fix or workaround would double the performance of the 68060.

If I design a new mainboard, I could squeeze a little more performance out of the 68060 than the original Q60 by hardware. E.g. by faster DRAM or overclocking. But only a small amount compared to the almost 100% that a software solution to the QLiberator problem would gain.