Hi Peter,
>> NB: I am sure that Qlib programs normally do NOT modify their own code
>> whilst running ("normally" means that they do not contain some new
>>external non-Qlib keyword that would so that).
Does your statement include the creation of new executable code?
No it doesn't. If the program creates new code somewhere in memory, and
then jumps to it, this is not covered by my statement. However, that,
per se, should not create trouble with the caches - unless I'm mistaken.
It is my understanding that the Instruction cache would just see that a
bra or jmp is made to code which isn't in the cache yet. That's a
typical cache miss and should not create the problem. If that program
code then is modified while the program is running, then, yes, there
might be a problem, and my tests would not have shown that.
Other than self-modifying code, the cause might come from QLiberator
abusing the top three address bits, relying on the hardware *not* to
treat them as different addresses. A terribly dirty method.
I can agree with that.
So that QLiberated executables can work, the hardware must read or write
the same data for the up to eight different addresses represented by
variations of A31, A30, A29. The external DRAM of a Q40/Q60 will
partially do that, because of incomplete address decoding (luck that I
didn't have enough PLD pins). But the caches don't. They will use
different entries for different addresses, as they should.
Agreed.
Best regards
Wolfgang
_______________________________________________
QL-Users Mailing List
