Writing $$external extensions with QLib

[pjw]

I think, an "!" after the keyword makes the generated QLib job like EX, it does not suspend the Caller.

QLib doesnt like a terminating separator. Just put something after it, like ! 0

[HAOUI]

it would be interesting to know, if a QLib job (not necessarily an external) works in a similar way than SBASIC or totally different. If an _obj is a sum of bytes which are run by the runtime system or something different.

Very good question. I am rather an assembler programer but my answer would be :

They are not deeply different. QLIB is not a true compiler as it doesn't convert Basic program to an excutable machine code program.
It lies on tokenized items as QSAV/QLOAD do. This is why QLIB compiled programs don't run really faster than a BASIC program when executed under SBASIC.

However, QLIB still has some benefits :

• Better packaging of programs especially when distributed
  Smaller sizes than raw BASIC sources (when RUNTIMEs are not embeded)
  Faster load and start when QSAV/QLOAD are not used
  Ready for multi-tasking under QDOS when no SMSQ/E SBASIC

Also, I think QLIB does some useful optimisations for Integer and Float expressions or for some loop structures control.

To make it short, If you write/use your own programs and have SMSQ/E, no need for QLIB. Simply EXEC your BASIC source program, preferably QSAVED.
Alain

[HAOUI]

I've tried out the new PARSTR$ keyword from the tkparex.zip. This now works on my DCOPY program, I no longer have to include the quote marks. One thing to notice is that if the result from PARSTR$ is copied back to the parameter, it stops with an error. This is noted in the SBASIC/SuperBASIC Reference Manual. To check whether it is the Interpreter making the call, OJOB(-1) gives the owner job. If that is zero, then S*BASIC has made the call. So now, one can avoid it if called from a compiled job.

This is a normal behviour for TK2 original commands. However, the tkparex archive uploaded was a first quickly & dirty POC.
I have worked out some improvements and changed slightly strategy.
The 4 tk2 original commands are re-written in a way that they adapt their behaviour depending if used in a compiled program ot not. 2 additional commands similar to PARNAM$/PARSTR$ are dedicated to external parameters to avoid confusion. All 6 commands work safely in compiled or interpreted programs (crash proof ;0).
Any way the name returned by PARNAMEX$/PARSTREX$ (which are strings) can not be always assigned to procedure args to be returned unless actuals parameters was string type. This is simply a coercion compatibility.

Keep connected.
Alain

[HAOUI]

... Wherever possible, if I need an extension I try to write is in assembler. This is because I started out with a 4K computer and still find it traumatic to use 16K to implement an UPPER$ function. But dont mind me. You never know when you might need some extra kit in your toolbox!

I totaly agree, as you, I've always written extensions in assembler, but being older and busier man, I found some benefits to write some BASIC programs (quicker to write and run for start but much longer to make reliable) especially for Proof Of Concept. Memory no more limited with QPC2...

Thank you for your thougths.
Alain

[RalfR]

They are not deeply different. QLIB is not a true compiler as it doesn't convert Basic program to an excutable machine code program.
It lies on tokenized items as QSAV/QLOAD do. This is why QLIB compiled programs don't run really faster than a BASIC program when executed under SBASIC.

That makes me think about QLiberator as been suggested as "the definitive Compiler" for TT's Futura....and then there comes SBASIC. So perhaps they are are more close to each other. But who may knows this realy...

[RalfR]

I think, an "!" after the keyword makes the generated QLib job like EX, it does not suspend the Caller.

QLib doesnt like a terminating separator. Just put something after it, like ! 0

But the manual states this. And that worked under QDOS.

[pjw]

I think, an "!" after the keyword makes the generated QLib job like EX, it does not suspend the Caller.

QLib doesnt like a terminating separator. Just put something after it, like ! 0

But the manual states this. And that worked under QDOS.

All I can say is: Try it! I know I had problems in the past with trailing separators, so I always use this construct in programs that are to be compiled with Qlib. The exact details are lost in the mists of time..

[EmmBee]

The same with the QLib decompiler. There were hundreds of ideas from people to enhance it, the first was to make its window go further than 512x256. But there comes nothing up until now. We have to wait .

It seems like Martin has done the perfect job of decompiling Q_Liberator back into its SuperBASIC source. However, the final program is totally unreadable. It is chock full of statements that read var this, var that, procFun this, procFun that, procFun other. There is no description at all of what the code is doing. At the moment it is impossible to know where to make any changes. This is why I have decided to go through and rename all the variables and procFun names to more readable and understandable ones. This turns out to be a very time-consuming task, but I have managed to get 60% the way through. I do intend to complete this process, but this may take some time, yet. When complete, we will all be able to understand the code and easily make any changes we deem necessary.

I don't know whether anyone else has tried this renaming; if so please let us know how you're getting on.

[EmmBee]

... Wherever possible, if I need an extension I try to write is in assembler. This is because I started out with a 4K computer and still find it traumatic to use 16K to implement an UPPER$ function. But dont mind me. You never know when you might need some extra kit in your toolbox!

I totaly agree, as you, I've always written extensions in assembler, but being older and busier man, I found some benefits to write some BASIC programs (quicker to write and run for start but much longer to make reliable) especially for Proof Of Concept. Memory no more limited with QPC2...

I am very pleased to hear that you are both enthusiastic about assembler. About the decompiled Q_Liberator, I have been thinking of the future, where we are going, etc.

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.

Michael (EmmBee)

[pjw]

First things first: You are cleaning up the code at the moment. I dont want to disturb or duplicate that effort. When you feel ready, Id be happy to take a look and add any suggestions I might have, as will hopefully other interested parties. Once we are clear about whats going on and how it works, then would be a good time to start improving things, IMHO.
Also, I thought Marcel wrote that he already had disassembled much of the machine code.. No point in duplicating the effort, especially since the best possible effort may already have been done..