QLiberator decompiler

[EmmBee]

once.zip

(25.61 KiB) Downloaded 104 times

I have run the new dm511_bas through my once program, which can identify any possible spelling mistakes. This produced the following output ...

Code: Select all

Candidates for possible spelling mistakes ..
Name(s) occurring once only ..
At line 440   var0448$
At line 2320   row%
At line 2320   col%
At line 4310   var06980
At line 13280   pipe_22
At line 21620   pipe_150
At line 28680   pipe_32000
At line 29250   var0C10

Line 440 seems to be wasting about 9k of memory with an unused string array.
At line 2320, row% and col% are necessary for the return results.
At line 4310, var06980 should be var0698 (from line 4230).
The pipe_22, pipe_150 and pipe_32000 are simply device names.
And at line 29250, var0C10 I guess should really be var0C08 (from the FOR loop at line 29200)

I would also like to point out that at lines 11790, 12050, 12300 and 12580, the variable ad8 has never been assigned a value and so would default to 0, i.e. #0

2390 fra$ = fra$ & procFun25050$((var0658 - 1)) & "_"
or did you really mean to do
2390 fra$ = fra$ & procFun25050$((var0658 - 1),1,LEN(procFun25050$((var0658 - 1)))) & "_"
when the additional parameters will be thrown away.

Lines 16300 and 16340
You've currently got the "NEXT loop" after the "END REPeat loop". Perhaps you should reverse these. But to get it outside of the "END IF"

23680 This line is a bit of a mouthfull. Since there is already an END FOR var03A0 at line 24090, this line could be written more simply as ...
23680 IF (((mark%(var03A0) = 129) OR (mark%(var03A0) = 2)) AND (fil$(var03A0,1) = ">")) THEN var0B28 = var03A0 : ELSE NEXT var03A0 : RETurn

I've never used DiskMate 5, I'm just going on the Basic.

[Martin_Head]

I will have a look into these things.

Line 4310, yes that looks like a typo on my part when converting the GO TO's back into REPeat loops

Line 16300 must have confused me a bit, as I put that REMark there. It can be quite hard trying to tidy up the decompiled code , identifying REPeat, NEXT's and EXIT's. When the original author throws real GO TO's in all over the place, as in DM5. I thinks there's a GO TO into the middle of a SELect somewhere in there. There's a lot of places in DM5 where I looked at, and thought, what the heck's going on.

Line 2390, I did not mean to do it, Ask the original author I will try hand decompiling the things you mention, in case the decompiler got it wrong.

I don't understand what your problem is with the pipe_'s. I think DM5 has it's own pipe device driver.

[EmmBee]

I am continuing to rename the vars in the new decompiled QLiberator source. Here is a snippet ...

Code: Select all

1090       REPeat tokens
1100         IF NEXTLINE  THEN
1110           EXIT tokens : REMark NEXTLINE means End Of Program has occurred
1120         END IF

The way that NEXTLINE is being used, it appears to return End_of_Program. Being a machine code function, I cannot rename it. Has it been disassembled, yet?
Am I on the correct path?

MB

[Martin_Head]

I am continuing to rename the vars in the new decompiled QLiberator source. Here is a snippet ...

Code: Select all

1090       REPeat tokens
1100         IF NEXTLINE  THEN
1110           EXIT tokens : REMark NEXTLINE means End Of Program has occurred
1120         END IF

The way that NEXTLINE is being used, it appears to return End_of_Program. Being a machine code function, I cannot rename it. Has it been disassembled, yet?
Am I on the correct path?

MB

If it's any help there is always a STOP added at the very end of the program, after any Proc/Fun definitions there may be.

[EmmBee]

This renaming is rather like painting by numbers, except you don't know what the colours are. It's all a guessing game. It's actually like writing your very own program - that's the kind of thinking involved. I've had to look up some details from the Turbo Parser to fathom out some of the indexes used. In QLiberator, rather than use SELect clauses, they use On GOTOs and jump to line numbers. I've discovered that in a simple assignment, the last part is read in twice - haven't found out why yet. So far I have discovered 7 variables that are declared but not used. They have been renamed "unused_" with a number.

I'm about 1/3 the way through.

Ralf, about sedit_63 - have you renamed the vars, yet?

[RalfR]

Ralf, about sedit_63 - have you renamed the vars, yet?

No chance, I haven't look in the original code for years. I will have to wait, until the damaged HDD is rescued. I unfortunately haven't saved the 63 version to an flp, as far as I know. I will have to look, how far my flp versions are, so perhaps upload an earlier version. The only thing I have changed was the use of the WMAN colors (also in the extensions for the block colour), the height of #6 (the editor window) and the use of WMOV from easyptr (which could also be used in the QLib source, much better than their way).

[Martin_Head]

once.zip
I have run the new dm511_bas through my once program, which can identify any possible spelling mistakes. This produced the following output ...

Code: Select all

Candidates for possible spelling mistakes ..
Name(s) occurring once only ..
At line 440   var0448$
At line 2320   row%
At line 2320   col%
At line 4310   var06980
At line 13280   pipe_22
At line 21620   pipe_150
At line 28680   pipe_32000
At line 29250   var0C10

Line 440 seems to be wasting about 9k of memory with an unused string array.
At line 2320, row% and col% are necessary for the return results.
At line 4310, var06980 should be var0698 (from line 4230).
The pipe_22, pipe_150 and pipe_32000 are simply device names.
And at line 29250, var0C10 I guess should really be var0C08 (from the FOR loop at line 29200)

I would also like to point out that at lines 11790, 12050, 12300 and 12580, the variable ad8 has never been assigned a value and so would default to 0, i.e. #0

2390 fra$ = fra$ & procFun25050$((var0658 - 1)) & "_"
or did you really mean to do
2390 fra$ = fra$ & procFun25050$((var0658 - 1),1,LEN(procFun25050$((var0658 - 1)))) & "_"
when the additional parameters will be thrown away.

Lines 16300 and 16340
You've currently got the "NEXT loop" after the "END REPeat loop". Perhaps you should reverse these. But to get it outside of the "END IF"

23680 This line is a bit of a mouthfull. Since there is already an END FOR var03A0 at line 24090, this line could be written more simply as ...
23680 IF (((mark%(var03A0) = 129) OR (mark%(var03A0) = 2)) AND (fil$(var03A0,1) = ">")) THEN var0B28 = var03A0 : ELSE NEXT var03A0 : RETurn

I've never used DiskMate 5, I'm just going on the Basic.

I have had a look at some of these issues in the original compiled code.

440 DIM var0448$(17,512) . The variable 0448 does not seem to be used in the main BASIC program, but there may be a reference to it in one of the BASIC extensions in the code. Somewhere around bits of text about sectors. DIM var0448$(17,512) looks like storage for a track of a floppy disk 2*9 sectors of 512 bytes. I think DM5 can do some floppy disk direct sector manipulation. I don't know how, or if, the extensions access this array. But I have seen it done by PEEKing and POKEing the variables area directly.

4310 IF (var0628% = 2) THEN EXIT var06980 : END IF . Yes a typo on my part.

29250 IF procFun14520(var0C10,0,0) THEN. I think this may be a typo in the original source code, and this should be var0600. Look a bit further down to see something similar.

Code: Select all

29340   PUT #4\(var0C00 + var0BE0%(var0C08)),sektor$(var0C08);
29350   IF var0B00 THEN
29360    var0600 = Q_ERR
29370    IF var0600 THEN
29380     IF procFun14520(var0600,0,0) THEN
29390       NEXT var0C08
29400     ELSE

procFun14520 is error handling and the variable is the error number.

16340 NEXT var0698. I think that maybe I should have left this as - 16340 GO TO 16110

Line 2390, I've checked the original compiled program, and hand decompiled to check.

Code: Select all

2390    fra$ = fra$ & procFun25050((var0658 - 1),1,LEN(procFun25050((var0658 - 1)))) & "_"

          0080 03D0      get fra$
0024F96C  58             precede keyword
            D4 0658      get var0658
          0092 08014000  1
0024F976  0C             -
            66 00        no seperator
            92 08014000  1
0024F97E  66 00          no seperator
          58             precede keyword
            D4 0658      get var0658
          0092 08014000  1
0024F98A  0C             -
            66 00        no seperator
            CE 0000A8C6  call proc/fun
0024F992  AC             LEN()
            66 00        no seperator
            CE 0000A8BE  call proc/fun
0024F99A  42             &
          8C 0001 5F     "_"
          42             &
0024F9A0  0084 03D0      assign fra$

In case anyone is interested, I have attached copies the raw output from the decompiler for DM5, A list of the variable references and their names, A list of line numbers with offsets from the start of the compiled program.
And a copy of my dump of the DM5 object file. If you do a search for line 12170, You will find somewhere the decompiler got confused by pure bad luck. I can't quite remember what went wrong, But I think it was the FFFFFECC 00000004 on the END FOR above it. It thought the CC00000004 was a IF..THEN.

[HAOUI]

Hi Martin & everybody,

My question may be off-topic but I need your help.

I am looking for fetching name parameters (i.e. file name without quotes) passed from interpreter to $$external procedures in a similar way that TK2 PARNAM$() does.

I am able to access the name table of the caller and see all passed parameters but it is not enough because S*BASIC supposed calling a machine code procedure hadn't created an entry in his return table. The $$external job, either.

As $$external job is able to copy back these parameters when it ends, I guess it holds some information about these entries.

Any idea ?

Thanks,
Alain

[EmmBee]

Hi Martin & everybody,

My question may be off-topic but I need your help.

I am looking for fetching name parameters (i.e. file name without quotes) passed from interpreter to $$external procedures in a similar way that TK2 PARNAM$() does.

I am able to access the name table of the caller and see all passed parameters but it is not enough because S*BASIC supposed calling a machine code procedure hadn't created an entry in his return table. The $$external job, either.

As $$external job is able to copy back these parameters when it ends, I guess it holds some information about these entries.

Any idea ?

Thanks,
Alain

Hello Alain. Welcome to these QLiberator Decompiler pages!

The idea is instead of typing DIR "win1_", we type DIR win1_ without the quote marks. Our want is to be able to do this with QLIB $$externals.
I believe this could become the responsibility of the RUNTIMES. The Runtimes could recognise that the $$external is requesting a string input, and also recognise that the Interpreter is trying to send a float variable. In this case, Runtimes could decide to send the name of the variable as a string, rather than the float variable itself.

Perhaps Martin or Marcel would care to give their opinion on whether this could be achieved.

EmmBee

[HAOUI]

The idea is instead of typing DIR "win1_", we type DIR win1_ without the quote marks. Our want is to be able to do this with QLIB $$externals.

Yes, absolutely.

I believe this could become the responsibility of the RUNTIMES. The Runtimes could recognise that the $$external is requesting a string input, and also recognise that the Interpreter is trying to send a float variable. In this case, Runtimes could decide to send the name of the variable as a string, rather than the float variable itself.

I don't totally agree. In interpreted Basic, passed parameters are not converted to args type of procedures. If you wish fetch a name parameter from a PROC or FUNC, you have to use TK2 PARNAM$() or PARTYP$() which are completely not working in compiled programs or $$external.

Forthmore, I dont see on which criteria RUNTIMES will decide to convert or not names to strings as it cannot know what we want inside the compiled $external and the interpreter has already put actuals parameters on the name table.

IMHO, What we need instead, is PARNAM$() or PARTYP$() working for compiled $$external. I already wrote similar functions as assembler extensions that work for $$external (see sources and binary in attached archive). I called them PARNAMEX$() and PARSTREX$(). I am not totally happy with these extensions but it does work. I think it could be better written with some more information. Also, it could be easily amended to support interpreted programms and replace tk2 original functions.
Any feedback, suggestion welcomed.
Alain

paramex.zip

(13.85 KiB) Downloaded 99 times