Q_Liberator malaise

[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

Of course, but how is that related to Qliberator, as it would not work (reliably) on such a system anyway?

[Artificer]

Hi Martin,

On my Q60 a first quick look at Q60test01 runtimes was not good. Booting into smsq/e 3.41 cache in writethrough Launchpad fell over with error 35 index out of range. Qdock however was Ok. Testing Qcoco, ACP and SQRV form Qdock resulted in all failing with error 35. Launchpad - bodged with its compiled runtimes disconnected still failed with error 35. Moving onto copyback enabled, fontview a qliberated program I have without runtimes incorporated wihich previously failed with copyback was OK as was the recompiled variant without FOR loops.

Why the test QLIb Q60test01 runtimes should affect programs compiled with and included with other runtimes is something I don't understand. At the moment q60test01 runtimes are not a solution but the tests still indicate that the FOR loop handing of the runtimes is the incompatibilty problem for the Qx0. I haven't tonight look at the asm supplied. Is it possible to alter the code so that only float variables are used . On the Q60, QPC2 etc this would not be a problem as smsq/e speed difference of float vs interger variable on loops is minimal. That way the bit signalling might be sidelined.

[Martin_Head]

Hi Martin,

On my Q60 a first quick look at Q60test01 runtimes was not good. Booting into smsq/e 3.41 cache in writethrough Launchpad fell over with error 35 index out of range. Qdock however was Ok. Testing Qcoco, ACP and SQRV form Qdock resulted in all failing with error 35. Launchpad - bodged with its compiled runtimes disconnected still failed with error 35. Moving onto copyback enabled, fontview a qliberated program I have without runtimes incorporated wihich previously failed with copyback was OK as was the recompiled variant without FOR loops.

Why the test QLIb Q60test01 runtimes should affect programs compiled with and included with other runtimes is something I don't understand. At the moment q60test01 runtimes are not a solution but the tests still indicate that the FOR loop handing of the runtimes is the incompatibilty problem for the Qx0. I haven't tonight look at the asm supplied. Is it possible to alter the code so that only float variables are used . On the Q60, QPC2 etc this would not be a problem as smsq/e speed difference of float vs interger variable on loops is minimal. That way the bit signalling might be sidelined.

Sorry, I realised later that I should have made the modification to all variable accesses in the runtimes, not just the FOR handling ones. Which there are libel to be a lot of. And a lot of care may be needed not to screw anything up, or miss any.

The error 35's make some sense, if a FOR loop control variable is used with an array. The array handling routine would try to read the FOR variable from the name table, which still has the the flags set in it. So it reads some rubbish data from an incorrect address, that happens to be outside the arrays index range and triggers an error.

I have been thinking about trying to do away with the flags, and just have float FOR loops. But I think that might be problematic. I think the runtimes set and treat the FOR control variable name table entries as normal float or integer variables. And the purpose of one of the flags is to say that 'this is a FOR variable' which uses about 20 bytes of space. Hence the 'FOR type error' message you can get

So a possible danger I can see in doing away with the flags, is if a normal variable is later used as a FOR variable, there wont be enough space for the extra FOR information like the end value and the step value.
Something like

Code: Select all

200 x=12.3
.
.
300 FOR x=1 to 10
.
.
400 END FOR

X would only have 6 bytes allocated for it in the variables area, and the later FOR will most likely trash other variables in the variables area.

[BSJR]

...
Why the test QLIb Q60test01 runtimes should affect programs compiled with and included with other runtimes is something I don't understand...

The two mentioned test programs QCoCo and SQRV do not have Qlib_run included but expect this to be part of the system's Boot process. So if any change there is not compatible with the 3.36 version problems are to be expected.

Martin,
Using the same var name as a FOR loop and reassigning it outside the loop is normal practice for me.
Also REP loop names can be assigned values and used as a normal var according to the Jan Jones book.

BSJR

[dilwyn]

Not been following this discussion too closely, so forgive me if this post is repetition or unhelpful.

If the Auto Integer FOR is the root of the problem, would using Qlib_Patch_Obj to turn off the AUTO setting in a compiled program achieve a similar result? This still wouldn't deal with programs which have DEF_INTEGER commands, but should allow programs like Launchpad (which don't use DEF_INTEGER) to work.

[Artificer]

Dilwyn wrote: would using Qlib_Patch_Obj to turn off the AUTO setting in a compiled program achieve a similar result?

Answer : no its not a solution. Compiling with AUTOF set to off or patching AUTO to off fails to alter the behaviour of QLiberated programs with copyback.

The problem with FOR INT/FLOAT loops seems to be the way the runtimes mark loop variables as integer of float using 'spare' bits. Altering the sbasic source to not use FOR loops seems to resolve the issue as does Wolfgang Lenerz patches with v3.42 smsq/e.

[Mark Swift]

Hello,

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

I hadn't thought of that, using the pointer as a data address without clearing the upper bits will of course cause data cache misses.

I have been thinking about trying to do away with the flags, and just have float FOR loops. But I think that might be problematic...

Would it be easier to clear the upper bits of the pointer before it's used as an address?

search the code for 'code 9e', 'code a4', and 'autof' to see the bit setting and and checking.

Example bit clearing...

Code: Select all

; ...

; code 9E - get FOR control variable
L1888   move.w  (a4)+,d2             ;get FOR variable reference from program
        movea.l $04(a2,d2.w),a3      ;get pointer to value from name table
        move.l  a3,d0
        
        lsl.l	#3,d0                ;clear bits $1F, $1E and $1D
        lsr.l	#3,d0
        exg     d0,a3

        btst    #$1E,d0              ;flag for float FOR?
        beq.s   L18A0                ;trigger a 'FOR type error' message


; ...

; code A4 - Start the FOR
L18A6   movea.w (a4)+,a0             ;get the FOR variable reference
        adda.l  a2,a0                ;point at the name table entry
        move.l  $0004(a0),d0         ;get pointer to value from name table
        movea.l d0,a3                ;..into A3
        
        lsl.l	#3,d0                ;clear bits $1F, $1E and $1D
        lsr.l	#3,d0
        exg     d0,a3
       
        addq.w  #$04,$0012(a3)       ;one more selections
        btst    #$1D,d0              ;test AUTOF flag?
        beq.s   L18CE                ;..off

; ...

; code A2 - END FOR
L192C   move.w  (a4)+,d5             ;get the FOR variable reference

        movea.l $04(a2,d5.w),d0      ;get pointer to value from name table
        lsl.l	#3,d0                ;clear bits $1F, $1E and $1D
        lsr.l	#3,d0
        movea.l d0,a3
        
        move.l  a4,$0014(a3)         ;save address of next program instruction just past the END FOR?
        movea.l a3,a0
        btst    #$00,$01(a2,d5.w)    ;check the type lower byte
        beq.s   L195E                ;it's a float

; ...

; code A0 - used in mixed FOR selections
L19B8   move.l  a4,d7
        move.w  (a4)+,d2             ;get varaible reference
        
        move.l  $04(a2,d2.w),d3      ;get name table variables offset
        lsl.l	#3,d3                ;clear bits $1F, $1E and $1D
        lsr.l	#3,d3
        movea.l d3,a3
        
        move.l  $0014(a3),d3         ;get address of next program instruction just past the END FOR?
        beq.s L19B0                  ;it's zero, skip over the END FOR pointer in the compiled program

; ...

[Martin_Head]

I have been thinking about trying to do away with the flags, and just have float FOR loops. But I think that might be problematic...

Would it be easier to clear the upper bits of the pointer before it's used as an address?

That's what I did in the Q60test01 runtimes, similar to your example. But I did not stop to think that I also needed to to the same for every variable access, not just the FOR ones.

I know where a lot of them will be. But I expect there will be some buried ones. I will need to pluck up a bit of enthusiasm to go hunting for them.

[Martin_Head]

Martin,
Using the same var name as a FOR loop and reassigning it outside the loop is normal practice for me.
Also REP loop names can be assigned values and used as a normal var according to the Jan Jones book.

BSJR

There's an example of the problem on page 6.6 of the QLib manual 'FOR type error'. Where a float variable is used as a parameter for a procedure call, that uses the parameter in a FOR loop.

I assume it works for you because the compiler notices that you are using the same identifier for a normal variable, and a FOR control variable. It flags it as a type '07' float control variable, which uses more variables space than a normal variable. So when you use it as a normal variable, it just has more storage space than it needs.

If you decompile a QLib program you will find that the REPeat becomes a variable assignment like var1234 = 0

However in SuperCharge and Turbo, REPeat generated no code in the compiled program

[Martin_Head]

I have had another go at modifying the QLib runtimes for the Q60 problems.

I don't know if I have found everything, but I have added another 7 patches.

The modifications so far are in

Code: Select all

Routine		Label
-------		-----
Code 80		L0CA0		Fetching variables onto the stack
Code D2		L0CDE
Code D4		L0CEE

Code D6		L0E8A		Assigning variables
Code D8		L0EA6
Code 84		L0D8E

Code 78		L119C		Getting name list entries

Code 9E		L1888		Original FOR changes
Code A4		L18A6
Code A2		L192C
Code A0		L19B8

I have avoided anything involving strings and arrays, as I don't see why they should have any connection with FOR control variables.