Q_Liberator malaise

[pjw]

I havent been able to follow this in great detail recently, but do I understand correctly that the new QERR file is patched with code to flush the cache before or after certain operations? If so, will the patched QERR still work on non-Qx0 platforms? Or do we need to compile separately, or use a different QERR for the different platforms?

[RalfR]

Good question, I asked it a few posts ago, whether Q_ERR is now the source of all evil.

[Martin_Head]

The original Q_ERR plays the same game as FOR in the runtimes. Where it uses a bit in the name table, value pointer, as a flag. Which seems to upset the Q60 cache.

This flag marks a name table entry as being handled by Q_ERR_ON. Q_ERR maintains a list of small bits of code that convert each procedure to a function. What I have done is to do away with the flag bit (like I have in the runtimes) and added a marker to the list of small bits of code.

When Q_ERR_ON or Q_ERR_OFF is used. It searches the list of small bits of code looking for the marker that ties the supplied command name to an entry in the list. Now, this is going to be a bit slower than the original system, and I don't know if it will be noticeable on slow systems.

It was suggested that I may need to flush the cache, (self modifying code?) so I did two versions of Q_ERR. And it looks like the flush is needed.

I do the flush whenever the small bits of code are altered. (Q_ERR_ON and Q_ERR_OFF) If you have multiple names supplied, like Q_ERR_ON "INPUT","OPEN_IN","OPEN_NEW" It will do 3 flushes, one for each name. I don't know if you could get away with just one.

I used the code that was suggested to do the flush, by looking at the system variables and doing the flush if it thinks it's a 68040 processor.

As to if my Q_ERR code is safe to use on any QL system, is that I don't know for sure. I have only tried it on QPC2, And I don't know if any further problems will show up when it is tried with a Q60 on more programs.

As for my replacement runtimes, I don't know that I recommend it for development work, as the error trapping for a 'FOR type' error is disabled, so you could get mysterious crashes during testing. And the AUTOF feature also no longer works, so you might see speed issues on an original QL where a FOR loop runs in floating point instead of integer. But I doubt you would notice anything in a Q60 system.

[dilwyn]

Thank you very much for your work on this Martin.

[pjw]

Great work Martin!

It seems a pity no one could lend you a suitable system to try on. Im sure that would have been so much easier! Supposedly Tony Tebby once debugged a hard disk driver in Germany while he was situated in England! I cant remember the details but it sounded equally impressive

The fixes you propose seem to work although, more importantly, you seem to have uncovered the root of the issue, namely that the top three bits of certain addresses are used for purposes that they were not designed for.

Ideally, to my mind, would be to devise a different scheme for doing this that would work transparently for all systems and without slowing things down by having to test for CPU type and flushing caches..

Any thoughts? Anyone?

[pjw]

PS: Needless to say, devising such a scheme is one thing, implementing it would be quite something else! That would require a good understanding of how Qlib works. The good news is that Martin has gone to quite some trouble to analyse and annotate all the toolkits that form part of Qlib!

Im preparing a re-release of the latest distro with Martin's commented code. Its just so bloody hot! so it could take a few days..