Derek_Stewart wrote: Wed Feb 05, 2025 11:00 pmIs it possible to alter the Qliberator compiler to produce the code the patch does?
Unfortunately, there seems to be a problem: If an unpatched (MC) program is started from a patched Q-Dock, i.e. Q-Dock only runs in the writethrough cache, then the started program also only runs in writethrough mode, so it seems to have "inherited" something. And no, the started program is not a Q-Dock daughter job.
Why and how is not yet known, but Wolfgang is informed.
An idea that occurred to me, which of course could be completely wrong:
Basically, QLib programs with Copyback cache enabled already run on the Q60. Programs that don't run (e.g. Q-Dock and Qtrans [this is just an example, as they are regurlarly used]) contain code from easyPTR. So it could be that the problem lies there. Possibly also in connection with the address registers abused by QLib. Or when QLib programs access the PE.
This is just an idea for now, it must be checked.
Last edited by RalfR on Mon Feb 17, 2025 7:14 pm, edited 1 time in total.
This is indeed true for my QLibbed programs. All mine contain toolkits of one form or another, usually DJToolkit, Display_cde, Basconfig, Easyptr and the QLiberator extensions files (Qerr, Qpipe, QLib_ext)
Display_cde is a prime suspect in this case. It has a small data area within its code used to get the results of an iop.flim call, which I'd forgotten about. Does not modify any of its own instructions, but does modify those 4 words. I suppose that doesn't help matters.
Don't know if DJToolkit modifies itself in any way - Norman?
RalfR wrote :
Basically, QLib programs with Copyback cache enabled already run on the Q60. Programs that don't run (e.g. Q-Dock and Qtrans [this is just an example, as they are regurlarly used]) contain code from easyPTR. So it could be that the problem lies there. Possibly also in connection with the address registers abused by QLib. Or when QLib programs access the PE.
EasyPTR is not the key problem. Qliberated programs using QPTR suffer similar problems as easyPTR programs with copyback enabled. Your point about abuse of address registers might be a cause of the problem as QLIb error messages when programs crash do sometimes suggest the code has lost the place.
Dilwyn wrote :
Display_cde is a prime suspect in this case.
I doubt that Display_cde is the explanation as my own Qlib/QPTR compiled programs suffer the same problems with copyback and I do not use Display_cde.
dilwyn wrote: Mon Feb 17, 2025 6:10 pm
Display_cde is a prime suspect in this case. It has a small data area within its code used to get the results of an iop.flim call, which I'd forgotten about. Does not modify any of its own instructions, but does modify those 4 words. I suppose that doesn't help matters.
That's not particularly nice, but also not particularly dangerous. As long as what you write in the program area is data and never executed as code, the data in the data cache and in memory is identical and are read back correctly.
If you make the CPU read something back as an instruction that you've just written as data, what's in the instruction cache might not be identical to what's in memory (CPU thinks "He's just written data to x. I'll put that in the data cache for later use. Then "he wants to execute code at x, I happen to have that in instruction cache and save myself a read".
These cases need a cache flush. The data and instruction caches on 680x0 are completely separate and have no automatic interaction whatsoever.
Lets always keep in mind that generating new code without cache flush would be just as wrong as modifying existing code without cache flush.
Anyway, my gut feeling goes more toward the abuse of the upper three address bits by now.
