QLiberator decompiler

[pmonstad]

Hi! You can remove my address as it is obsolete. You can include a valid email address: pmonstad@gmail.com. Thanks!

[pjw]

Martin,
there may be an issue with the decompiler: Theres a program I have that compiles and runs perfectly with Qlib 3.36, but if I use your decompiled Qlib 3.36, it errors when run. The funny thing is that the temporary wrk file compiles and runs ok, but if I QSAVE the file from SMSQ/E and compile the sav file, then I get the error. Any ideas?

[Martin_Head]

Martin,
there may be an issue with the decompiler: Theres a program I have that compiles and runs perfectly with Qlib 3.36, but if I use your decompiled Qlib 3.36, it errors when run. The funny thing is that the temporary wrk file compiles and runs ok, but if I QSAVE the file from SMSQ/E and compile the sav file, then I get the error. Any ideas?

Have I got this right. If you use the work file created by QLiberator, then compile it with my decompiled Qlib. It works OK. but not with a QSAVE file.
Which suggests that there is something different about the QSAVE file. Can you compare them to see what's different.

What kind of error do you get, Is it a compile time QLIb error, or a QDOS error. Or is it a run time error.
If you can get a successful compile. Can you decompile it and try to spot any differences with the original.
You could also try comparing two compiled versions of your program. One made with the original QLIB, and one made with the decompiled version. To see where the differences may be.

At one time (earlier in the thread), I was trying to get the decompiled QLib to compile itself as an exact copy of the original. That way I would be confident the the decompile was correct. However I was not very successful, I was having a problem with the order of the names in the name table. All the names were there, but some were moved about a bit. I think I would at least need to replicate the same operating system of the original compile.

[pjw]

Hi Martin,
Yes, you got that right. I can only report on one side of the issue: I QSAVE a program and then compile it with V3.36. Everything works as expected. The same qsaved file, when compiled with the recompiled-decompiled V3.36 (lets call it V3.36x) does not. It fails with a Qlib runtime error on a command that reads a heap address, claiming it cant find what it expects to find there.
The resulting obj files should have been identical, yet the 3.36x file is 14 bytes shorter (10276 vs 10262) and there are numerous differences, mainly in the beginning, starting at byte position 39.
The workfile exception was reported to my by EmmBee. Perhaps he could help with this(?) as Im not able to produce workfiles at present (despite ploughing the manual). I never used this facility, always preferring qsaved files.

[dilwyn]

Unless I'm missingsomething, with the Basic program loaded enter:
LIBERATE ram1_filename

will produce a work file called ram1_filename_wrk

To make the compiler proceed automatically to the second phase of compilation, change it to:

LIBERATE ram1_filename,

(i.e. comma at the end)

[RalfR]

LIBERATE ram1_filename

will produce a work file called ram1_filename_wrk

And that should be identical to the same QSAVEd one.

[pjw]

Yes, thanks. I already tried that, but couldnt make it work. I was trying to find another way of producing a workfile to answer the quetions asked.
Q-Liberator was written for a different age. I dont think it and SMSQ/E get on all that well together on all occasions. For example doing a LRESPR qlib_obj causes my system to crash after I try to quit Qlib again (and it was probably crashed before that, considering the rubbish it produced). It may be clashing with some toolkit, or the current SMSQ/E or QPC2, or large screen sizes, directory depths,.. I dont know, and havent yet had time to figure it out.

[pjw]

I disassembled the start of the object code. I know its unlikely to answer why my program crashed, but it is interesting that V3.36 and V3.36x - which are supposed to be the same program should produce such different results using the identical input (sav) file: Here is the original:

Code: Select all

*  DISA-Listing: ram1_Stats336_dis      filetype  1
        section code
        filetype 0
        data    $13CC
start   equ     *
*       Job Header
L0000   bra     L0084
* 
        dc.w    $0000,$4AFB
        dc.w    $0005
        dc.b    'Stats                 '
        dc.w    $0000,$0146,$0000,$2728,$0000,$1B86,$0004,$0000
        dc.w    $17F6,$000F,$0080,$0200,$0000,$0200,$0080,$0238
        dc.w    $0000,$25EE,$0000,$182A,$0000,$13CC,$0000,$0320
        dc.w    $0000,$0000,$0000,$0000,$FF00,$0000,$0000,$0000
        dc.w    $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
        dc.w    $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
        dc.w    $0000,$0000
L0084   bra     L008C
* 
        bra     L00F0
* 
L008C   moveq   #$00,d0         ; SMS_INFO
        trap    #$01
        ..

and here is V3.36x's version (here called V3.37):

Code: Select all

*  DISA-Listing: ram1_Stats337_dis      filetype  1
        section code
        filetype 0
        data    $13D2
start   equ     *
*       Job Header
L0000   bra     L0084
* 
        dc.w    $0000,$4AFB
        dc.w    $0005
        dc.b    'Stats                 '
        dc.w    $0000,$0146,$0000,$271C,$0000,$1B84,$0004,$0000
        dc.w    $17F4,$000F,$0080,$0200,$0000,$0200,$0080,$0238
        dc.w    $0000,$25EC,$0000,$1828,$0000,$13D2,$0000,$0320
        dc.w    $0000,$0000,$0000,$0000,$FF00,$0000,$0000,$0000
        dc.w    $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
        dc.w    $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
        dc.w    $0000,$0000
L0084   bra     L008C
* 
        bra     L00F0
* 
L008C   moveq   #$00,d0         ; SMS_INFO
        trap    #$01
	..

Even the dataspace is different..

[EmmBee]

The last time I tried this I got ambiguous name errors for SCRXY and WINDSZ, and so could not even get any compilations.
On one other earlier try, I did successfully get it to work, both for the _wrk file and also for the _sav file. The results were identical.
I would guess that the problem might lie with SMSQ/E, in choosing the wrong definition of a name to be used.
So, the problem is down to name-clashes. Please note that these problems occurred with both the original v3.36 and v3.36x
There doesn't appear to be anything intrinsically wrong with either version.

P.S. At lines 191 and 194, shouldn't the ";" semi-colon be a "," comma ?

EmmBee

[pjw]

The last time I tried this I got ambiguous name errors for SCRXY and WINDSZ, and so could not even get any compilations.
On one other earlier try, I did successfully get it to work, both for the _wrk file and also for the _sav file. The results were identical.
I would guess that the problem might lie with SMSQ/E, in choosing the wrong definition of a name to be used.
So, the problem is down to name-clashes. Please note that these problems occurred with both the original v3.36 and v3.36x
There doesn't appear to be anything intrinsically wrong with either version.

The program I sent you was just to illustrate a point. It isnt the issue here. Your note to me that you had successfully compiled a working copy by going via a workfile I took as an added mystery, but now I am unsure.. The fact remains, as stated previously, that the decompiled-recompiled Q-Liberator produces a different output to the original. In this case one that didnt work. My disassemblies of the outputs of the different compilers of the same file demonstrates that.

P.S. At lines 191 and 194, shouldn't the ";" semi-colon be a "," comma ?

I dont think so. However, my program is not relevant here other than to demonstrate the problem. The fact is: in this case Qlib 3.36 produces a working result while Qlib 3.37 appears not to. The thing to find out now is whether the outputs of these compilers differs in some cases, and if so we need to find out when and why so it can be fixed.