Writing $$external extensions with QLib

Anything QL Software or Programming Related.
User avatar
tofro
QL Wafer Drive
Posts: 1789
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Writing $$external extensions with QLib

Postby tofro » Wed Feb 12, 2020 8:25 am

HAOUI wrote:
tofro wrote:
Ralf R. wrote:
I think, an "!" after the keyword makes the generated QLib job like EX, it does not suspend the Caller.


That is really a nice idea to build a self-contained multi-threaded S*BASIC program, however:

It should, but it doesn't, - At least not on SMSQ/E.
I used to have an idea why not, but forgot...

Tobias


Indeed, this often crashed my systems. My be related to copying back parameters or multiple versions, mods and patchs.
A simple rule I learned : Have a normal, good & successful return from QLIB program or GOTO reset button ;o)
Alain


If I remember right, that wasn't the problem - I think an ! command simply didn't spawn a new job on SMSQ/E.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Ralf R.
Gold Card
Posts: 266
Joined: Fri Jun 15, 2018 8:58 pm

Re: Writing $$external extensions with QLib

Postby Ralf R. » Wed Feb 12, 2020 8:50 am

You may look after the thread "Resident QLib Jobs", where the problem was discussed.


HAOUI
Chuggy Microdrive
Posts: 53
Joined: Tue Dec 14, 2010 2:17 pm

Re: Writing $$external extensions with QLib

Postby HAOUI » Wed Feb 12, 2020 2:08 pm

DeaQlib.zip
(18.77 KiB) Downloaded 8 times
EmmBee wrote:Per, you have mentioned recently about hex%, bin% and the PEEK variety wanting to be included for. We are needing to get inside "NEXT_TOKEN", which is a machine code procedure which reads the next token. This would need to be disassembled, amended to cope with the above-mentioned features and re-assembled. I don't do any assembly myself, so would not know how difficult this would be. So, may I ask you both, would you be interested in investigating this, please?
There are 2 routines actually, NEXT_TOKEN with 6 parameters and RNAME with 4 parameters. The full spec is ..

NEXT_TOKEN sym1%, sym2%, sym3, sym4$, End_of_Stmt%, End_of_Line%
RNAME name_adr(sym3), p0%, struct_base%, FOR_ranges%

The above appears in the program at lines 19440 and 19480. The reason why RNAME is important is that in the case of PEEK, sym1% will obtain a value of 6, which means a name, and here, the ON GOTO will jump to the line number that calls RNAME, so this may affect matters or not, I don't know.

This is certainly very exciting. If it cannot be done, we could always try to do this in S*BASIC, but my guess is that assembly language would be more appropriate here. I look forward to hearing what you think.


If you want to have an idea, have a look to attached archive, it includes deassembled RNAME and NEXT_TOKEN ready to be modified and reassembled. RNAME is fully commented (comments are mine, so please be indulgent).
Alain


User avatar
Ralf R.
Gold Card
Posts: 266
Joined: Fri Jun 15, 2018 8:58 pm

Re: Writing $$external extensions with QLib

Postby Ralf R. » Wed Feb 12, 2020 5:23 pm

Hi Alain,

would be nice, if you can put a comment line about the usage in the dissassembly, like e.g.

* Usage: "PRINT[#ch] para1, para2"

so we know how much parameters are needed. Have you discovered, what these keywords do?


HAOUI
Chuggy Microdrive
Posts: 53
Joined: Tue Dec 14, 2010 2:17 pm

Re: Writing $$external extensions with QLib

Postby HAOUI » Wed Feb 12, 2020 6:18 pm

Ralf R. wrote:Hi Alain,

would be nice, if you can put a comment line about the usage in the dissassembly, like e.g.

* Usage: "PRINT[#ch] para1, para2"

so we know how much parameters are needed. Have you discovered, what these keywords do?


Not guessing why do you want to modify this extensions if you don't kwow what they do ?
Not sure I am able to do it from assembler side.
RNAME is quite trivial code copying from arrray (16) in first parameter to 1 to 3 others parameters when given but I cannot say what is copied.
NEXT_TOKEN is a more complex code as it contains a table of offsets (14 entries) and jmp is made to one of these locations.
So we have to pull out all these jumped codes also. This new archive contains the complete assembler for NEXT_TOKEN.
Alain
DeaQlib2.zip
(20.04 KiB) Downloaded 8 times


EmmBee
Trump Card
Posts: 158
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Writing $$external extensions with QLib

Postby EmmBee » Thu Feb 13, 2020 3:59 pm

HAOUI wrote:Not guessing why do you want to modify this extensions if you don't kwow what they do ?
Not sure I am able to do it from assembler side.
RNAME is quite trivial code copying from arrray (16) in first parameter to 1 to 3 others parameters when given but I cannot say what is copied.

Interesting .. I note from the assembler listing that RNAME starts off by fetching the first parameter as an integer.
Since in the Basic program RNAME is called with a float as the first parameter, my guess is that this routine does not work as expected, in any case.

The idea was that this routine might need to be modified in the case of the new PEEK functions.
However, I have discovered that they already work in QLIB, E.g. num = PEEK(!8!18) gives exactly the same result in both QLIB and SBASIC.
In light of the above, there would appear to be no longer a need to modify that particular extension.
Last edited by EmmBee on Thu Feb 13, 2020 4:16 pm, edited 1 time in total.


User avatar
NormanDunbar
Aurora
Posts: 842
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Writing $$external extensions with QLib

Postby NormanDunbar » Thu Feb 13, 2020 4:15 pm

EmmBee wrote:Interesting .. I note from the assembler listing that RNAME starts off by fetching the first parameter as an integer.
Since in the Basic program RNAME is called with a float as the first parameter, my guess is that this routine will not work as expected, in any case.


It will work fine. You could even pass a string as the first parameter and as long as it contained digits, it would be coerced to, and read as, an integer by the function. For example:

Code: Select all

CLS #1
CLS #1.1234
CLS #"1"


All work and clear channel #1.

Cheers,
Norm.


Why do they put lightning conductors on churches?
If at first you don't succeed, don't take up skydiving!
If you think your job is pointless, remember, there's someone in Germany who fits indicators to BMWs.
User avatar
Ralf R.
Gold Card
Posts: 266
Joined: Fri Jun 15, 2018 8:58 pm

Re: Writing $$external extensions with QLib

Postby Ralf R. » Thu Feb 13, 2020 4:36 pm

I think, as Marcel has dissassembled and commented all of QLibs inbuilt extension (a few in the decompiler thread), he is the person to give us a bit light.


EmmBee
Trump Card
Posts: 158
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Writing $$external extensions with QLib

Postby EmmBee » Fri Feb 14, 2020 5:16 pm

NormanDunbar wrote:
EmmBee wrote:Interesting .. I note from the assembler listing that RNAME starts off by fetching the first parameter as an integer.
Since in the Basic program RNAME is called with a float as the first parameter, my guess is that this routine will not work as expected, in any case.


It will work fine. You could even pass a string as the first parameter and as long as it contained digits, it would be coerced to, and read as, an integer by the function. For example:

Code: Select all

CLS #1
CLS #1.1234
CLS #"1"


All work and clear channel #1.

Cheers,
Norm.


Yes, I agree. What you say is perfectly true, but that is not what I meant. Sorry - my fault. I should have explained the problem in a bit more detail.

RNAME will receive as first parameter a value obtained from calling ALCHP, which would be well over the short integer maximum of 32767.
RNAME is going to have a difficult job of copying the long integer value back to the SuperBASIC short integer ones, in parameters 2 to 4.
That is why I think it might not work as expected.
I suppose it really depends on what the purpose of RNAME is - which is not immediately obvious.

Cheers,
Michael


User avatar
NormanDunbar
Aurora
Posts: 842
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Writing $$external extensions with QLib

Postby NormanDunbar » Fri Feb 14, 2020 10:07 pm

Ah, right. Ok, forget what I said (typed?) Above in that case.

Cheers,
Norm.


Why do they put lightning conductors on churches?
If at first you don't succeed, don't take up skydiving!
If you think your job is pointless, remember, there's someone in Germany who fits indicators to BMWs.

Who is online

Users browsing this forum: Google [Bot] and 8 guests