The Sinclair QL Forum

Here is the latest QLiberator.

This is a much tidied-up version, with
ON..GOTO's converted to SELect On's
Multiple line IFs converted into single line IF's
All to aid readability - and thus, understandability.
Per Witte's latest version of QLIB_run, V3.42 is now included.
Enjoy!

Thanks, Michael.

Would like to hear from the boys, if that match their source.

Thank you, EmmBee.

Puh, I have spent a few hours to read the actual QLib source. Not quit really easy to understand, my respects to EmmBee. I have seen, that you use FPOS and GET from TK2 but that is not mentioned in the update text. What was formerly used?

It would be good to know, what the different extension keywords mean and what they do (I just know the PE keywords). That would make the source better understandable.

RalfR wrote:Puh, I have spent a few hours to read the actual QLib source. Not quit really easy to understand, my respects to EmmBee. I have seen, that you use FPOS and GET from TK2 but that is not mentioned in the update text. What was formerly used?

The program uses POS for FPOS, and NEXT_TOKEN for reading from the work file. This has 6 parameters … NEXT_TOKEN sym1%, sym2%, sym3, sym4$, End_of_Stmt%, End_of_Line% Their usage is detailed from line 21140 onwards.

RalfR wrote: It would be good to know, what the different extension keywords mean and what they do (I just know the PE keywords). That would make the source better understandable.

Agreed. I’m wondering whether Per Witte can be of help, here.

Here is one keyword that I do know the meaning of: NEXTLINE. The meaning is: EOF(#wrk). This appears at line number 1100. It has to be so because this is what is always checked for before input is taken. NEXTLINE is written in C style manner, returning with a zero exit status if all is well, indicating that another line can be read from the file. If something goes wrong, such as EOF(#wrk) then it returns with an error code. This is the direct opposite of what SBASIC does, which returns zero for failure and non-zero for success. This difference also adds to the difficulty in reading the code.

Having read through the code, and having gained some more understanding, here are two suggestions for renaming two procedures at the end of the each_line loop

start_of_line …………….rename to … initialise_trace
remainder_of_line ….. rename to … process_line

start_of_line is defined at line 4220 which restarts the numbering of the statements from 1. The machine code procedure, “ GENop 4” does this.

Remainder_of_line is defined at line 2980 and processes every statement on the line.

Yesterday I did a little more work on one of Qlib's system toolkits,
Qlib1_bin. Not much, but thats three hours Ill never get back..

So, I dissembled it and made some half-hearted attempt to document
parameter usage (see QLib1_BIN.txt). Assembling the dissembly with
Qmac produces an identical binary to the original.

I didnt try very hard to figure out what the various commands do but
I and others can fill in what we know or discover and add to the
documentation over time.

The dissembly can be optimised slightly (Qlib1_list), but it also
contains some commands that dont appear to be used in Qlib itself, so
they could be removed. Some commands replicate commands found in TK2.
To my mind these too could be removed (or at least one could try and
see what happens), and commands with different names that do the same
as commands in TK2 could be removed also, and the commands renamed in
the Qlib_bas code. That would imply that the Qlib compiler would only
run on Qdos/Minerva with TK2 or on SMSQ/E. The object code produced by
it would not be affected.

When youve stopped screaming, consider: The retro brigade already have
their Qlib compiler. Its called Q_Liberator V3.36. It works and will
continue working in the retro environment for eternity or until just
before the North Pole comes to a boil.

Those who wish to progress should be interested in a leaner, meaner
Qlib V4x. My suggested modifications would only be a first step to
knocking Qlib into shape. Re-working the code helps to understand it
better for each iteration, and once it is understood it can be
improved as, indeed, we already see happening (heres looking at you,
EmmBee).

Just my penny's worth.

Hi Per,

Really excellent work.

I must admit to not using most or all the command in QLIB_BIN, but the command commands should be documented correctly.

I would not worry about compatibility, if something does not work on older QDOS system, then it is not loaded, unlike other OS systems, where they have to patch the system to bodge the operation of out of date software.

Personally, I would not use anything other SMSQ/E or Minerva, mainly due to the use of multi tasking basic, once used it is a total miss.

Before you sink anymore time into this, these are my diassemblies of the QLib_obj utilities that I did two years ago.

Derek_Stewart wrote:Hi Per,

Really excellent work.

No, really sloppy - compared to mk79's, at least..

Derek_Stewart wrote:I must admit to not using most or all the
command in QLIB_BIN, but the command commands should be documented
correctly.

These are not Qlib user toolkits. They are part of the compiler itself.
Most commands are pretty specialised and dont have much use outside
of Qlib itself. But yes, for the sake of understanding how Qlib works,
we need to document them.

Derek_Stewart wrote:I would not worry about compatibility, if
something does not work on older QDOS system, then it is not loaded,
unlike other OS systems, where they have to patch the system to bodge
the operation of out of date software.

Personally, I would not use anything other SMSQ/E or Minerva, mainly
due to the use of multi tasking basic, once used it is a total
miss.

I basically agree with you, but its not up to me; its
a "community effort".

I dont believe in backward compatibility at all costs, but nor do I
believe in riding roughshod over it. Its a balancing act.

mk79 wrote:Before you sink anymore time into this, these are my
diassemblies of the QLib_obj utilities that I did two years
ago.

My time wasnt wasted if it poked you into sharing your efforts
Very nice and useful analysis! Any more?

I "fixed" one of them up to make it Qmac compatible (movea.l
(sb.gtlin).w,a2 ! Wassat?! bsr.w ? Which assembler were you using?

I also removed some redundant commands and their code (BINPUT, BWRITE,
SINPUT, SWRITE, READSETUP). (It turns out ALCHP and RECHP are too
different from the TK2 versions to be removed without fiddling the
BASIC source as well.)

The two assembler source files you posted are now named Qlib1_asm and
Qlib2_asm to fit in with the current nomenclature. Theyre included
with the attachment, below.

I also added a few lines of code to the BASIC to save me (or anyone)
from having to load all those toolkits into memory before compiling
the compiler, not least of all because Qlib1_bin smashes ALCHP/RECHP:
This is included in the attachment as Header_bas and could be dropped
right into the BASIC source file.

I used Qlib 3.44 to compile the resulting file (without loading any toolkits!),
using the new Qlib1_bin and Qlib2_bin. I used the resulting object code to
compile itself again (and again). While this is not proof that it is bug free,
it is a pretty good stress test. I wont muddy the waters by including the
result here. Interested parties have all they need to try it out for
themselves. I leave it to EmmBee to publish the "official versions".

pjw wrote:My time wasnt wasted if it poked you into sharing your efforts
Very nice and useful analysis! Any more?

Yeah, almost all of it, I really spent far too much time on this thing...

I "fixed" one of them up to make it Qmac compatible (movea.l (sb.gtlin).w,a2 ! Wassat?! bsr.w ? Which assembler were you using?

No assembler, but my disassembler is IDA Pro, which at some 500€ per year is fortunately paid for by my employer... I even created some Python extensions for it that can decode SuperBasic function tables and stuff, it really is quite powerful.

IDA Pro produces the official syntax as described in the Motorola manual (e.g. in the address mode tables it is specified as "(xxx).W", therefore "(sb.gtlin).w"). I have created a post-process in Perl that normally fixes this and more stuff, but for some reason qutil2 was not processed by the latest script (I just took what's there and that is dated 2019 while gen_util2 is 2020).

Cheers, Marcel