Q_Liberator malaise

[Peter]

One of the things to check might be to try out earlier versions of SMSQ/E to see whether copyback cache stopped working properly with Qliberated programs at some point.

That seems to me to be an important point.

While ago I did try version 2.98 (patched for 68060) which was tested with a lot of software 25 years ago using copyback cache, and probably the best version still released by Tony Tebby. The cache management extension from Mark Swift was required back then. If I remember correctly, there was no difference in behaviour of the two or three QLiberated programs I tried. SMSQ/E booted from RAM or ROM makes no difference.

More systematic investigation would indeed be nice, since we have already seen that primitive Qliberated programs do not immediately malfunction. 25 years ago, all this was not in my focus, because the software I used was not QLiberated. And after the license war, I stopped using SMSQ/E until it became free software. So there is little I can say about the history. Also I can not become QLiberator investigator today, that would distract me way too much.

I have to concentrate on hardware and low level software. To develop a new 68060 mainboard is an extreme effort, especially if a public release is the ultimate goal. I was bringing this to attention in the hope that someone software oriented would care enough to look into gaining 68040/68060 compatibility.

As already mentioned, this does not necessarily require QLib compilation, since it brings no speed improvement. If another form of software deployment acceptable for QLib users can be achieved with a new tool, that's also fine. My gut feeling says the latter has a higher chance to succeed, but that might also be totally wrong.

[Peter]

Regarding Qlib, I find it hard to believe that people as smart and knowledgable as those who created Q_Liberator would end up producing what was then commonly known as "impure code", ie code that modifies itself during runtime.

On the other hand, if software works correctly writethrough, but not copyback, self-modifying code is almost the only possible reason. Except timing dependency or direct hardware register access, which would be even more impure. (Direct QL screen access would not be a problem since caches are flushed frequently enough to ensure visibility.)

[RalfR]

While ago I did try version 2.98 (patched for 68060)

Why patched? I always thought TT had tested this with a Qxx too. Of course, that may have been a wrong assumption. The log from v2.94 says that TT has already made cache adjustments for Qxx, so this must have already been included natively in the code.

Of course it could have only been for 68040, I don't know. Is there a difference in the cache compared to 68060?

I have to concentrate on hardware and low level software.

Naturally. It would have been TT's job to make it work. Unless the 68040 behaves differently than the 68060.

[Peter]

I don't remember well, but the patch was probably due to the MOVEP instruction not implemented on the 68060. It was certainly unrelated to our issue. 68060 caches are twice 68040 size, but that also should not matter.

[RalfR]

There may be an issue with code sharing,
ie where multiple instances of a program use the same program code but
separate data areas (I havent thought this through yet,) but otherwise not
much.

Regarding Qlib, I find it hard to believe that people as smart and
knowledgable as those who created Q_Liberator would end up producing what
was then commonly known as "impure code", ie code that modifies itself
during runtime. For starters such code cant be shared, viz what I wrote
above. But Qlibbed code can be shared without a problem, unless some ad hoc
toolkit prevents it!

That was also my experience on the QL. I've had a few QLib programs on an EPROM card and they've never had any problems, even with multiple instances.

But that ultimately has nothing to say, because Liberation Software wasn't able to test anything else during QL times, although they have test the Atari with the 68030. The proper testing was probably left to TT, as he developed SMSQ/E.

[Peter]

That was also my experience on the QL. I've had a few QLib programs on an EPROM card and they've never had any problems, even with multiple instances.

That means nothing. I also have no problems with the Q68 or SGC. No CPU < 68040 will have issues with self-modifying code!

[RalfR]

No CPU < 68040 will have issues with self-modifying code!

And the cache of the 68030? I remember problems with a few programs during my MegaST4 with hyperCache 030 time. There was a command "CACHE ON/OFF" to prevent this.

[Peter]

As I already posted here viewtopic.php?p=61150#p61150, the 68030 has no write cache and would not be affected by self-modifying code.

[pjw]

Apologies for harping on this, but logic demands..

QJump are quite clear on the self-modifying code issue. They write in the hotkey documentation:

- -I This tells the Hotkey System that the program code is 'impure'
(ie. it modifies its own code). This means that
code cannot be shared by every copy of the program - this therefore
means that each time that the program is called, a copy of the original
code is made from which the program runs. For this reason, you should
consider using HOT_LOAD for such programs. The most common programs
which fall within this category have been written under BCPL or compiled
with Supercharge or Turbo.

No mention of Qlib, and the Turbo issue seems to have been fixed.

Now, I use Qlib programs with the code sharing option all the time! This should simply not be possible if the code was self-modifying.

There is another reason why the copyback cache software itself may not work: That in some instances it fails to write back its contents, how, or when, it is supposed to.

[Peter]

This should simply not be possible if the code was self-modifying.

It is possible.

There is another reason why the copyback cache software itself may not work: That in some instances it fails to write back its contents, how, or when, it is supposed to.

That would mean the even more "impure" possibilities I have already mentioned: Timing dependency or direct hardware access. (Or an external bus master which does not exist in our case). Keep in mind that all data in cache remains consistent for all processes, if copyback is active. Also of course unmodified instructions.