Q_Liberator malaise

[RalfR]

I might be totally wrong here, so please don't shoot!

That was later incorporated in SMSQ/E. With 3.42, Copyback Cache is always ON.

[Andrew]

That was later incorporated in SMSQ/E. With 3.42, Copyback Cache is always ON.

Then can tests can be run in SMSQ/E 3.41 or older?

[RalfR]

Then can tests can be run in SMSQ/E 3.41 or older?

3.41 is ok.

[Peter]

That was later incorporated in SMSQ/E. With 3.42, Copyback Cache is always ON.

Except for programs with Wolfgang's specific patch of course.

[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.

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.

Yep, and that's the problem. You're just lucky if it wraps around to the proper (intended) address. I don't see why mis-using the upper address bits would relate to the cache at all.

[Artificer]

Hi Martin,

I have run your variable listing program on both the compiled versions on the sceen copy program, one with a FOR loop and one with a repeat loop. An integer variable of type $00 is present in both, so probably not the cause of copyback problems.

Now since the version of the screen copy program with a REPeat loop would run when QLib compiled with copyback I decided to look other programs. I have changed the FOR ..END FOR loops in a more complex QPTR based program that previously would not run with copyback to REPeat loops and recompiled with QLiberator. This also now runs on smsq/e 3.42 with copyback and without needing Wolfgang lenerz's patch. Makes me think that the copyback issue is due to FOR loop management by the QLib runtimes and may be due to the flagging of int vs float for FOR variables with bit tweaks.

[Martin_Head]

I have been thinking about trying to do a test reassemble the runtimes for the Q60, that during FOR's, after fetching the the offset into the variables area from the name table entry, and checking the status bits. It then clears those two bits before using the offset to access the actual variable data.

However I'm a bit reluctant at the moment, as I have found a few places in the runtimes where there are bits of code that don't seem to be ever called. And I have not yet figured out how they are ever accessed. One of them I have figured out is called by the QLIB_OVL program. I don't know if I add any extra code to the runtimes, if I will break something accessing these routines.

Another concern, is if a FOR variable is later used as a normal variable, then these flag bits will still be set, and may still cause problems.

Another thing I wonder about, not knowing how the caching works. Is how does the 68060 know the difference between code and data in a job. For example the FOR routines in the runtimes will patch the name table entry of the FOR variable in the data area of the job, between float and integer. Is these changes only kept in the cache, or is it written out to main memory.

[Peter]

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.

Yep, and that's the problem. You're just lucky if it wraps around to the proper (intended) address.

If a non cache hardware wraps around - and for QLiberator code to work, it has to - there is no luck involved. It is misuse, but it always works.
Note: Even emulators like SMSQmulator wrap around in order to satisfy QLiberator code.

I don't see why mis-using the upper address bits would relate to the cache at all.

Let me give an example: Lets assume data was written with an upper address bit not set. Without cache, the same data will be read with the upper address bit set. But with copyback cache, there are two possibilities:

If the affected copyback cache line is not yet written out to memory (bad luck) and the (expected same) data is read with an upper address bit set, it will read from external memory, not cache, which differ. (Because the cache address does not wrap around like external memory, generating a miss).

But if the copyback cache line was already written out to memory (good luck) and the data is then read with an upper address bit set, it will read from external memory, where the data does not differ. (Because the external memory address wraps around.)

[tofro]

Peter,

what I mean is that even on a '020, if there's memory where the upper address bits are set (not sure if that's the case on any existing hardware), obviously the "mis-used" address ends up somewhere else that the "non-mis-used" one

[Martin_Head]

I have had a go at altering the runtimes and reassembling it for a Q60 cache test.

I have worked out a couple of the routines that don't seem to get called. But there may be hidden problems with them after this build.

What I have done, is in the FOR handling routines, I have cleared the two bits that may get set, after they are read from the name table entry. But I have not altered the set bits in the name table entry. This should make them clean for any following memory accesses.

Search for 'Q60' in the source code to see what I have done. It's not very elegant, but it's just a test to see if it fixes anything.

I quickly tried a simple FOR loop (supplied), which still works in QPC2. Sorry, but I forgot to zip it up in a QL environment. But it should have a Qemulator/QPC2 header.

You can check the new runtime is loaded by typing Q_L to display the runtimes version.