QLiberator decompiler
Re: QLiberator decompiler
Hi! You can remove my address as it is obsolete. You can include a valid email address: pmonstad@gmail.com. Thanks!
Re: QLiberator decompiler
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?
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?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: QLiberator decompiler
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.pjw wrote: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?
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.
Re: QLiberator decompiler
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.
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.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: QLiberator decompiler
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)
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)
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: QLiberator decompiler
And that should be identical to the same QSAVEd one.dilwyn wrote:LIBERATE ram1_filename
will produce a work file called ram1_filename_wrk
4E75 7000
Re: QLiberator decompiler
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.
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.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: QLiberator decompiler
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:
and here is V3.36x's version (here called V3.37):
Even the dataspace is different..
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
..
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
..
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: QLiberator decompiler
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
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
Re: QLiberator decompiler
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.EmmBee wrote: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.
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.P.S. At lines 191 and 194, shouldn't the ";" semi-colon be a "," comma ?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?