The Sinclair QL Forum

pjw wrote: SAVE ram1_test_bas
QSAVE
LIBERATE
<>
My preferred method for QLib-compiling stuff is to use the first
method described (above, under the code): Make a change to the code,
QSAVE. Click Compile. Test. Repeat. But clearly that doesnt work if
the source code contains binary or hex numbers.

Currently, Q-Liberator first goes through the work file and changes all hex and binary values into floats. This cannot be done to _sav files because people might complain about all their hex and binary values having disappeared.

Q-Liberator contains a mixture of both SuperBASIC and machine code routines. One of these is NEXT_TOKEN, which only occurs once in the program, but at present doesn’t cater for hex and bin tokens. This routine has already been disassembled – by Alain HAOUI, in February, last year. I don’t do any m/c work myself, but we are needing some help to modify this routine to accept the hex and bin tokens. This is how it looks in SuperBASIC …

NEXT_TOKEN sym1%, sym2%, sym3, sym4$, End_of_Stmt%, End_of_Line%

The hex or binary value would be returned as a float – in sym3
In the context of where such a value would appear …
sym1% = 11 indicating a float value
sym3 = the float value itself
All other parameters, sym2%, sym4$, End_of_Stmt% and End_of_Line% would remain unchanged.

If we can get this working, then this should make Per very happy. QLIB would then work with either a work or a _sav file, as the preliminary conversion to floats would not then be needed.

Perhaps Norm might be interested in taking a look? The files are in DeaQlib2.zip and can be downloaded from https://www.theqlforum.com/viewtopic.php ... =30#p31831

EmmBee

Hi EmmBee,
I may have found a fix. Have emailed you.

Norm is interested, if Per's fix isn't as good as I expect it to be.

Cheers,
Norm.

PS. Puppy duties allowing of course.

So, we cracked it!

The following facts are incompletely documented anywhere outside the
SMSQ/E source code (AFAIK):

S*BASIC tokenises literal numbers, ie any number expressed as a number
in the BASIC source code (except line numbers and numbers in text) as
a 44-bit floating point number in a 48-bit package. In nibble
representation it looks like this: 0eee:mmmmmmmm, with 0eee being the
12-bit exponent and mmmmmmmm being the 32-bit mantissa.

The token value for literal decimals (until SBASIC, the only legal
representation) is the byte $Feee, ie F-anything.

SBASIC additionally allows for the representation of literal long word
integers as binary, or hexadecimal numbers if preceded by a % or a $,
respectively.

However, they too are coded as floating point numbers, as for
decimals, above! But, to enable their re-creation as binary, decimal
and hex in the listing, it is necessary to differentiate between them.
So they get slightly different tokens:

$Feee - any decimal number within the whole floating point range
$Deee - any number entered as a binary long integer
$Eeee - any number entered as a hexadecimal long integer

As EmmBee surmised, the core of the problem was in the keyword
NEXT_TOKEN. It doesnt understand binary or hexadecimal literals. So I
had a go at the NEXT_TOKEN code and changed what I hoped was the
relevant bit to this: (d0 contains the token/exponent and d2 a copy) The snippet above is based on the disassembly done by Alain. However,
since this keyword is part of a toolkit, QLib4_bin, I disassembled
that and used that disassembly instead.

Complex systems are rarely as simple as they may look to the
uninitiated who think they understand them! So Im taking the chance
that there is no deeper intention behind how these tokens were
formulated. Perhaps a future update was thought of to implement real
long and/or word integers? Or some other part of the system sees $Ceee
as something special? I dont know.

If anyone knows of a reason why the following assumption wouldnt work,
now would be a good time to come forward! 'Cause this is the solution
we plumped for:

$Deee, $Eeee, and $Feee (and $Ceee too) all have one unique property
in common, different from all other current token values: Their
two top bits are set. Thus by making just two tiny alterations to the
original NEXT_TOKEN code, from this:
to this and EmmBee making a few minor alterations to Q-Liberator's BASIC code,
the whole problem appears to have evaporated! Ie QLib V3.42, when
ready, should be able to process any SBASIC literal numbers without a
hitch.

Looks like it should work. Well done.

Cheers,
Norm.

Thanks Per, good work. Let's hope it all works now. Will look forward to the revised QLib.

I don’t do any assembler, but …

pjw wrote:

$Deee, $Eeee, and $Feee (and $Ceee too) all have one unique property
in common, different from all other current token values: Their
two top bits are set. Thus by making just two tiny alterations to the
original NEXT_TOKEN code, from this:

Sounds good to me, also, Norman Dunbar agrees.
Q-Liberator v3.42 is certainly on the way. This will be some time in August…

pjw wrote:

So RENAME ram1_test_sav to ram1_test_wrk and enter that name into the
console and compile.
Error: File not found

QLIB has certainly gone wrong, here! How can a file we know exists be reported as being not found? Some of these error messages that QLIB reports need looking at. There seems to be nothing wrong in attempting to compile a _wrk file as opposed to a _sav file. _wrk files and _sav files are the same, except for some filler bytes that are not used. Also, it would be helpful if the name of the file not found could be printed out, to aid our understanding. I am needing to look into all of this.

In real life, people tend to focus on the tasks they get involved with. They may choose to use some sophisticated software such as Q-Liberator (or other programs). Occasionally, things go wrong, and because of their focus, will find their own workarounds. Afterwards, the original problem gets forgotten. This seems to be human nature. As a consequence, these original bugs hardly ever get reported back to the software developers. In other words, there are probably several, if not many bugs still lurking in Q-Liberator that have gone unreported, unnoticed and still yet to be cured.

Our thanks go to Per Witte for reporting this problem about not being able to compile _sav files that contain hex or binary values. He did say that he should have done so before.

So please, report any bugs you may find to us, big or small. Bugs are always interesting. We can then address these issues. The SuperBASIC source code is also available, now. So, you might even try to fathom out the fix yourself – and even give us your code!

Please may I ask, have you ever encountered Q-Liberator crashing? If you were to ask me, then I do not remember - I am just like anybody else, as explained in real life, above! Seriously though, If Q-Liberator does crash, then we can help. I have written tracking software that can identify what definition it was in when the crash occurred. Not only that but will list all the definitions along with their parameter values on entry and exit. The idea is that this information can help to track down the bug. I have used this program on my own code, and this does work well. The latest version is v5, and I am currently working on a better v6. All good stuff.

If you want to report your own bugs found, and we can solve them, these can be included in the forthcoming Qlib version 3.42

EmmBee

EmmBee wrote:<>

pjw wrote:

So RENAME ram1_test_sav to ram1_test_wrk and enter that name into the
console and compile.
Error: File not found

QLIB has certainly gone wrong, here!
<>

I think it is probably just a deliberate "bug". QLib is trying to be helpful by hiding complexity: Since QLib itself creates the _wrk file, it pretends the user is compiling the _bas file directly. So the user enters "mdv1_test_bas". QLib creates "mdv1_test_bas_wrk", hiding "_wrk" from the user, and compiles that. Then the _wrk file is deleted and the user need never know it existed. Only when annoying people like me try to circumvent the system is the truth revealed. None of this happens with _sav files, because they are generated by the user, or at least outside the automated process.

I wouldnt worry about it! I dont think itll be an issue for people once QLib can compile all _sav files directly.

As for QLib crashing: Ive used V3.40 a lot and it never crashed on me, or gave me any kind of (unexplained) grief other than the hex/bin issue.

One minor niggle is that QLib uses its internal routines for things like peeks and pokes, as it overrides SMSQ/E's more flexible implementations. But there is no easy way to fix this as either the resulting code will no longer be compatible across the board, or QLib would have to re-implement the SMSQ/E version internally. IMHO its a minor issue and can relatively easily be worked around in the user's code.

I have had never problems with QLib 3.36 (the latest official version) during developing S_Edit or QPLQ. It runs as it supposed to do so. So I think, here are no very serious bugs in it.

Anyway, thanks for Emmbee to support this program.

pjw wrote:

EmmBee wrote:<>

pjw wrote:

So RENAME ram1_test_sav to ram1_test_wrk and enter that name into the
console and compile.
Error: File not found

QLIB has certainly gone wrong, here!
<>

I think it is probably just a deliberate "bug". QLib is trying to be helpful by hiding complexity: Since QLib itself creates the _wrk file, it pretends the user is compiling the _bas file directly. So the user enters "mdv1_test_bas". QLib creates "mdv1_test_bas_wrk", hiding "_wrk" from the user, and compiles that. Then the _wrk file is deleted and the user need never know it existed.

The above could explain the File not found report - but only for versions of Qlib up to v3.37. DELETE base$ & _wrk can be seen at line 26600 in PROCedure cleanup on v3.37. This was called from line 1420 in main. After that, it exits compile_work_file and, provided no command_string was provided, it would then go around the compile loop again to give another chance - but you wouldn’t get very far, as the _wrk file has already gone! You only got one chance at compilation, and that’s it.

Qlib v3.38 changed all that. The _wrk file now only gets deleted outside of the compile loop on the way out. One can now compile multiple times at will, changing settings and compiling to different _obj files, all in the same Qlib session. This applies equally to both _wrk and _sav files.

EmmBee