Q_Liberator malaise

[BSJR]

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.

That's not what I meant and would not do.
A Formal parameter can be anything as it's only a reference to the value from the calling line. Even a Formal string name can point to anything from a float to an integer array. An S*Basic feature that I believe Turbo does not like. That's why I like Qlib.
What I would do then is assign a Local var as copy of the Formal var and use that as the FOR index but outside the loop I often reuse the same var again.
The same is true for a SELect var. As I mentioned earlier SMSQe allows for INT vars here and I then name these explicitly in my SBasic and do not use the AUTOF option.

BSJR

[Artificer]

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

Hi Martin, I have good news this time. Programs such as QCoCo, ACP, EddIcon, My screen copier, and others that do not have older runtimes incorporated seem to run correctly, smsq/e 3.42 plus copyback.
However this is not true for all, SQRview (runtimes not incorporated) opens it windows correctly but creates a FOR type error when a image file is loaded for conversion.

It will take a while to check everything. For example qtrans ( which has runtimes incorporated ) does not run as is. If it is bodged to disconnet the run times then it appears to run OK browsing the drives but when it comes to executing a file via FileInfo2 it hangs. However it runs OK with Wolfgang Lenerz patch, so for some programs this patch is the solution and if writing new software, best to avoid FOR loops whear REPeat loops can be used.

So insummary at the moment with only a short time to test it looks as if your modification of QLib is great, although there are issues with some programs such as SQRview.
I will continue to test.

Cheers

[Mark Swift]

Hi Martin,

Yes, I too can confirm that the test program "q602test_obj" runs OK on my Q60.

Also QDOCK which previously crashed for me also loads without issue, although I am unable to test its functionality as I don't have it configured. I don't really use SMSQ/E on my Q60 so have to load everything from floppy disk which limits my testing abilities.

Looking through the runtimes source, a couple of things come to mind.

Can I suggest changing the move to sr instructions to andi.w #$C0FF,sr, in order to keep the trace enable bits and condition code registers intact?

Code: Select all

        move.w  #$0000,sr            ;back to user mode

Also, there is some code that you labelled as being related to releasing heap space.
Perhaps these too will need your fix.
I'm wondering if FOR variables might get released from the heap if they were defined as local within a procedure.

Code: Select all

---

; More from above
L0F4C   move.l  $0004(a3),d0         ;<---
          bmi.s L0F42
          
        movea.l d0,a                 ;<---
        movea.l (a0),a0
        move.l  -(a0),d1
        bsr.s   L0F1A                ;release heap space
        movea.l d2,a0
        bsr.s   L0F0C                ;release some heap space ??
        bra.s   L0F6A
        
; More from above
L0F60   move.l  $0004(a3),d0         ;<---
          bmi.s L0F42
          
        movea.l d0,a0                ;<---
        bsr.s   L0EFA                ;release a heap buffer
        
L0F6A   moveq   #-$01,d0        
        move.l  d0,$0004(a2)
        bra.s   L0F42

---

L161A   movea.l $0004(a3),a0         ;<---
        bsr     L0F0C                ;release some heap space ??

---

Tremendous. Many thanks.

[Martin_Head]

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

Hi Martin, I have good news this time. Programs such as QCoCo, ACP, EddIcon, My screen copier, and others that do not have older runtimes incorporated seem to run correctly, smsq/e 3.42 plus copyback.
However this is not true for all, SQRview (runtimes not incorporated) opens it windows correctly but creates a FOR type error when a image file is loaded for conversion.

It will take a while to check everything. For example qtrans ( which has runtimes incorporated ) does not run as is. If it is bodged to disconnet the run times then it appears to run OK browsing the drives but when it comes to executing a file via FileInfo2 it hangs. However it runs OK with Wolfgang Lenerz patch, so for some programs this patch is the solution and if writing new software, best to avoid FOR loops whear REPeat loops can be used.

So insummary at the moment with only a short time to test it looks as if your modification of QLib is great, although there are issues with some programs such as SQRview.
I will continue to test.

Cheers

Just noticed, I forgot to put the most important file in the zip

It's very possible I have missed more of the places that need the modification doing.
Any program that has the runtimes included is likely to fail, Also as I have made the runtimes bigger, things have moved inside it. There are some bits of code which don't seem to get called from within the runtimes itself. I don 't know if they are bits of redundant code that the programmers never removed, or bits of diagnostic code, or code that is called from some other part of QLiberator, like externals.

It might be worth testing programs that are still giving problems in QPC2, with the Q60 runtimes installed. Just to check if it still works OK

I also noticed this, look for the bit marked <<<<<<-----------

Code: Select all

; code 84 - assign a variable (string?)
L0D8E   move.w  (a4)+,d4             ;read variable reference from program
        move.w  $00(a2,d4.w),d5
        move.l  $04(a2,d4.w),d0

; Q60 test patch
   bclr  #$1E,d0
   bclr  #$1D,d0
   movea.l d0,a3            ;A3 should now be clean

        cmpi.w  #$0300,d5            ;substring
          bcc.s L0DF8                ;..no

; Substring and upwards
        move.b  #$02,$00(a2,d4.w)    ;change type to a normal variable
        subq.b  #$02,d5
          beq.s L0E06                ;float
          
          bcs.s L0E1E                ;string          

; Integer
        move.w  -(a5),d1             ;read the type stack
        subq.b  #$02,d1
          bgt.s L0DF2                ;integer

; What's this
        btst    #$05,$04(a2,d4.w)   <<<<<<-----------
          beq.s L0DEC

; The bit is set
        move.w  #$0202,$00(a2,d4.w)  ;set type to float variable
        move.l  $0002(a3),d5         ;get pointer to name list entry
        tst.b   d1
          beq.s L0DCA                ;float?

; A3 is the address to the variables area
        bsr     L0FEC                ;convert a decimal to a float

It tests bit 5, I don't know why. It's too low down to be a flag like the others.
I have not investigated it any further, yet.

I also noticed

Code: Select all

Possible bug in runtimes
; Scan the name table we just created
; Loop start
L03D2   move.b  (a0),d2              ;upper byte of type word
        move.w  (a0)+,d1             ;whole type word
          beq.s L03F6                ;undefined (odd type 00?) converts to integer

; Normal type
        subq.b  #$03,d2
          beq.s L03E8                ;sub string, or arrays
          
        subq.b  #$02,d1
          beq.s L03F0                ;float
          
        subq.b  #$01,d1
          beq.s L03F0                ;integer

; Is this a bug, should it be D2, not D1
        subq.b  #$04,d1
          beq.s L03FC                ;what's this? converts to float, type 07?

; Anything else or
; sub string, or arrays
L03E8   addq.l  #$06,a0  

It does not seem to make sense to me. But if the D1 was changed to D2 then it does.

[Martin_Head]

Hi Martin,

Looking through the runtimes source, a couple of things come to mind.

Can I suggest changing the move to sr instructions to andi.w #$C0FF,sr, in order to keep the trace enable bits and condition code registers intact?

Code: Select all

        move.w  #$0000,sr            ;back to user mode

I don't like that either, It also messes about with the interrupt levels.
But I don't want to make any changes to the source code for the runtimes I am adding the comments to. So I can do test builds and check I have not changed anything from the original.

Also, there is some code that you labelled as being related to releasing heap space.
Perhaps these too will need your fix.
I'm wondering if FOR variables might get released from the heap if they were defined as local within a procedure.

If I am understanding how the runtimes work, Integers and floats use the variables area in the jobs data area as might be expected. But strings are stored on the common heap, in user heaps. As their sizes may change at run time.

[Mark Swift]

Hi Martin

I also noticed this, look for the bit marked <<<<<<-----------

Code: Select all

        btst    #$05,$04(a2,d4.w)   <<<<<<-----------
 

It tests bit 5, I don't know why. It's too low down to be a flag like the others.
I have not investigated it any further, yet.

It's testing bit $05 of the high byte, which is bit $1D of the long word.

[pjw]

Looks like youve more or less cracked it, Martin! Fantastic work! Congratulations and thank you!

[Martin_Head]

Hi Martin

I also noticed this, look for the bit marked <<<<<<-----------

Code: Select all

        btst    #$05,$04(a2,d4.w)   <<<<<<-----------
 

It tests bit 5, I don't know why. It's too low down to be a flag like the others.
I have not investigated it any further, yet.

It's testing bit $05 of the high byte, which is bit $1D of the long word.

Ah, So it's one of the offending bits. I will take a closer look.