QLiberator v3.42

[Martin_Head]

I believe Martin had already applied the above patch to Qlib_obj before decompiling it. The reason I believe
this is because I have just created a Qlib external in QPC2, and after LRESPR ing the _obj file, it worked.
No further patches were required. I am wondering where, in the program, what line the change was made on.

I don't remember applying any patches before decompiling. But that does not mean that, it may not have been done in the dim distance past.

Or, maybe the patch was already implemented in the version I decompiled.

[pjw]

<>
I don't remember applying any patches before decompiling. But that does not mean that, it may not have been done in the dim distance past.

Or, maybe the patch was already implemented in the version I decompiled.

The one I got from you was the 3.36 Thierry patched version. I took the original Qlib_run V3.36, applied Thierry's patch and then applied TT's patch. This version I dissembled (disassembled?) added back some of your comments. I re-assembled the result and compared the binary with the patched original: They were identical (after a wee fiddle of the dissembly to undo Qmac optimisations). Then I changed the title string, partly to identify this runtime as V3.42, partly as a tentative first step at making changes, because I suspect Qlib uses fixed offsets and "known" values in its code (and in the OS!) to do its magic.

I tested this runtime (V3.42) with all Qlib-compiled programs I use, and then some. They all appeared to work as before. As I did not have time for more, I passed this back to the "Qlib gang" for their approval and any further testing/analysis. I dont see any immediate need for changing Qlib_run further. A first step might be to find out more about how it works..

Im happy to dissemble all the remaining Qlib toolkits , as with DISA it can be done relatively easily, but without any sort of organised "project management" it is hard to justify spending a lot of time, as efforts are liable to be duplicated or overwritten while in progress.

[pjw]

To make what the code does easier to understand, its useful to convert jump
offsets to actual labels, thus:

Code: Select all

L04D4   moveq   #$00,d0
        move.b  $00(a6,a3.l),d0         some byte code
        ...                             prepare it

        move.w  L04EE(pc,d0.w),d1       get corresponding table offset
        jmp     L04EE(pc,d1.w)           and go resulting label
*
L04EE   dc.w    L050C-L04EE             dc.w $001E
        dc.w    L0510-L04EE             dc.w $0022
        dc.w    L053C-L04EE             dc.w $004E
        dc.w    L050C-L04EE             dc.w $001E
        dc.w    L0526-L04EE             dc.w $0038
        dc.w    L052A-L04EE             dc.w $003C
        ...

L050C
        ...

L0510
        ...

        etc

However, I struggle to make sense of the following jump table:

Code: Select all

        ...
L05D2   moveq   #$00,d3
L05D4   move.b  (a4)+,d3
          bne.s L05DA
        move.b  (a4)+,d3
L05DA   move.w  L061E(pc,d3.w),d0
        jmp     L0620(pc,d0.w)
        ...

L061E   bra.s   L05D4

L0620   dc.w    $0B56
        dc.w    $045A
        dc.w    $FFF2
        dc.w    $FFF8
        dc.w    $04BA
        dc.w    $04F4
        dc.w    $0380
        dc.w    $03AC
        ...

        etc

We have a general idea of the function of this code: It is Qlib's main
interpreter bus to distribute the program flow to the routines which handle each
token. Its just I dont seem able to get my head around how the mechanism works.
Any help converting this table to something useful, like in the first example,
above, would be much appreciated.

[NormanDunbar]

My brain leaked out through my ears and ran across the street to the bus stop after reading that code!

Cheers,
Norm.

[NormanDunbar]

Ok, I'm back. To me it looks like L061E is placeholder of 2 bytes -- missing code might change that assumption.

The jump table at L0620 is effectively indexed by (D3.W -2) and D3 cannot be zero, or odd.

If D3.W is 2, then the first entry at L0620 is used and the jump is to L0620+$0B56.If D3.W is 4, the jump is L0620+$045A.

If D3.W is 6, the jump is L0620-$0E as $FFF2 will be sgn extended and is negative.

It's a weird way of indexing a table to avoid subtracting 2 from D3.W! At least, it looks that way.

HTH.

Cheers,
Norm.

[Martin_Head]

We have a general idea of the function of this code: It is Qlib's main
interpreter bus to distribute the program flow to the routines which handle each
token. Its just I dont seem able to get my head around how the mechanism works.
Any help converting this table to something useful, like in the first example,
above, would be much appreciated.

Would it not be -

Code: Select all

L0620  dc.w  L1176-L0620  ;$0B56 code 2 RI.TERM
           dc.w  L0A7A-L0620  ;$045A code 4  RI.NINT 

I worked out key code 2, $0B56 as -
$0620+$0B56 = $1176 So the routine at L1176 does key code 2

I think A4 is the compiled programs, Program Counter.

The skipping a zero at L05D4 I believe is due to, In the compiled program there is sometimes a zero inserted in front of the key code, if what follows the key code has to be on an even address.

If that's what you were trying to work out.

[pjw]

Thanks for your input, guys. It helped to jog my brain out of the rut. I worked out how the jump table works; turns out it is quite normal, despite appearances:

Code: Select all

L0620
       dc.w    L1176-L0620
       dc.w    L0A7A-L0620
       dc.w    L0612-L0620
       dc.w    L0618-L0620
       ...

This uncovered a whole set of labels that DISA wasnt able to see, all 113 of which had to be added by hand (with all the concomitant opportunities for gremlins to sneak in!) So even though the original binary and the re-assembled binary are identical, such a comparison wont reveal whether the label was put in the correct place. Anyway, a basic test suggests that most, if not all, are where they should be.

The object of the exercise is to make it easier to see how the main interpreter loop does its thing, with a view to updating it if and when needed. I just want to add back Martin's comments to the dissembly and test the binary some more before returning it.

[EmmBee]

Occasionally, there comes a need to calculate a null string at the very end of a string.
To illustrate, consider this short program ...

Code: Select all

100 x$ = "abcd"
120 PRINT #0,'x$ = "'; x$; '"'
130 PRINT #0,'x$(5 TO 4) = "';
140 PRINT #0, x$(5 TO 4); '"'

I've tried the above on Q-emuLator with JS ROM, but it fails.
It works with Minerva, and also on QPC2 in SBASIC.
Compiling with QLIB and running, it stops at line 140 with
an Index out of range error. The string length is only 4
so that 5 makes it out of range.
Of course, this is easy enough to workaround.
The challenge though would be to try and get the runtime (V3.42)
to recognize the null string.

[pjw]

Occasionally, there comes a need to calculate a null string at the very end of a string.
To illustrate, consider this short program ...
<>

Hi EmmBee,
Sorry Im not able to do anything with this at present, Im rather absorbed in other projects. Someone else might like to have a go?

I attach my latest dissembly of the patched Qlib_run (and all the other user-side toolkits that came with Qlib 3.36). Ive been using the resulting binaries for a while now without issue (not that that guaranatees there arent any..)

As I mentioned in my previous communication with you and other interested parties, I made some suggestions to re-arrange the furniture a bit. Since no further objections were forthcoming, those changes are included here. See the enclosed readme_txt file for details.

Any constructive feedback is welcome, as is any further analysis of these toolkits.

Qlib342b.zip

Qlib V3.42(b) user toolkits

(55.53 KiB) Downloaded 54 times

[RalfR]

Thank you for the effort