QPC2 MultiBASIC: Load SBASIC machine code function resident

[ql_freak]

Yes, I have tested it on QPC2. But I didn't know (and there seem to be others, e.g. Ralf) that NEW/LOAD/LRUN clears Machine Code extensions loaded in a (Multi)SBASIC job.

I have now run the Benchmark on Minerva under sQLux 1.1:

MultiBASIC is much slower than SBASIC, but also here the version with LEN is faster than the version with STRLEN%.

Timings were:
Minerva LEN 102 s STRLEN% 112 s
SBASIC LEN 18 s STRLEN% 22/23 (i.e. about 22.5 s)

So it seems, there is no advantage in fetching a parameter without CA.GT... To be absolutely sure, one should write a function STRLEN2% which fetches the string with CA.GETSTR (also without parameter checking) and benchmarks STRLEN% versus STRLEN2%. Perhaps I will do it in future. But even if there would be an advantage, I assume it would be very small. So now I will continue to implement the (one) missing function (which has one string parameter) in my Reflection toolkit and fetch this parameter with CA.GETSTR.

[janbredenbeek]

Minerva LEN 102 s STRLEN% 112 s
SBASIC LEN 18 s STRLEN% 22/23 (i.e. about 22.5 s)

I don't know how long the strings were, but I can imagine that copying a very long string onto the RI stack and then reclaiming the space would take significant time. Also, something like LEN(A$ & B$) will have to be evaluated first, then space found in the VV area (with possible shuffling of other SB areas), and finally copied to this VV area - and this is all happening before your function even has been called.

I've taken a look at the code and the SMSQ/E version looks very efficient. It gets the length directly from the VV area if the argument is a plain string, else calls CA.GTSTR which 'coerces' it into a string. Also, SBASIC is more like a compiler than the Minerva interpreter, the latter having to fit with the whole OS within 48K.

[ql_freak]

I don't know how long the strings were, but I can imagine that copying a very long string onto the RI stack and then reclaiming the space would take significant time.

Well that's (IMHO) the advantage of the solution without CA.GTSTR, the string passed MUST NOT be copied to the RI stack. This was, why I have thought it should be faster.

Also, something like LEN(A$ & B$) will have to be evaluated first, then space found in the VV area (with possible shuffling of other SB areas), and finally copied to this VV area - and this is all happening before your function even has been called.

The STRLEN%(''&variable$(line%) has only been used, cause my (test) STRLEN% function CANNOT handle string array variables, but can handle string expressions. But it's the same for the LEN and STRLEN% function.

I've taken a look at the code and the SMSQ/E version looks very efficient. It gets the length directly from the VV area if the argument is a plain string, else calls CA.GTSTR which 'coerces' it into a string. Also, SBASIC is more like a compiler than the Minerva interpreter, the latter having to fit with the whole OS within 48K.

Interesting! Thanks.

[pjw]

So an SBASIC daughter job is not the right way for testing. Never knew, that this happens. Any remarks for that in any documentation?

One just has to understand how it works. In SBASIC daughter jobs you need to load the extensions after loading the BASIC program. In fact a program can load all the extensions it needs at runtime. Thats usually the easiest. To avoid loading extensions repeatedly if you intend to RUN the program many times in the same session, you need some sort of flag to tell you whether or not they are present already. The same if you then want to run the same program in job #0 (The extensions, or other versions of the extensions, might already be loaded in job #0. There are many ways to do it. I often use (in pseudo-ish code):

Code: Select all

IF FINDNAME%("Extension", 1) = 0: LRESPR extension

The extra parameter here (, 1) is to ensure that only the nametable of the current job is searched, not the master nametable, owned by job '0. The FINDNAME% command can be found here But, as I said, there are other ways.

As Ive tried to say many times here, in SMSQ/E's SBASIC you can EXecute SBASIC code as if it were compiled. It runs almost as fast as compiled code anyway. But if your code uses bespoke extensions, you need to do something like the above to load them. This has the same effect as using rem $$asmb=extension in Qlib compiled code.

[RalfR]

But that doesn't explain Jan's statement that extensions loaded in a second SBASIC are (or should be) gone after a "New".

[pjw]

But that doesn't explain Jan's statement that extensions loaded in a second SBASIC are (or should be) gone after a "New".

Whats to explain? Someone decided that NEW should clear out everything. Same when you LOAD a new program in the same daughter BASIC: any previously loaded extensions are lost. CLEAR, on the other hand only clears out variable values. It doesnt remove extensions.

[RalfR]

So the question again: Where is this written?

[pjw]

So the question again: Where is this written?

There are a confusing number of SMSQ= and SBASIC-related manuals out there. I dont know if this information is recorded anywhere. Perhaps they just forgot to mention it? Clearly the behaviour is deliberate, and it is also quickly discovered empirically.

Another way to get around it is to use MERGE. This leaves any previous extensions intact.

[dilwyn]

RalfR wrote
> So the question again: Where is this written?

SBASIC manual:

SBASIC and Resident Extensions

Resident extensions linked into Job 0 (the initial SBASIC) are available to all SBASIC jobs. If extension procedures and functions are linked into other SBASIC Jobs (using LRESPR), they are local to those Jobs and will be removed when the Jobs die or are removed.

Note that, because of this feature, LRESPR cannot be used from a Job, other than Job 0, to load files which include system extensions (i.e. MENU_REXT, QTYP etc.).

No mention of what happens after NEW there.
Did a quick scan through Wolfgang's reference manual, didn't find anything there. Not looked in SMSQ/E sources.
If we can clarify this is correct, I could update the SBASIC manual.

[tofro]

RalfR wrote
> So the question again: Where is this written?

SBASIC manual:

SBASIC and Resident Extensions

Resident extensions linked into Job 0 (the initial SBASIC) are available to all SBASIC jobs. If extension procedures and functions are linked into other SBASIC Jobs (using LRESPR), they are local to those Jobs and will be removed when the Jobs die or are removed.

Note that, because of this feature, LRESPR cannot be used from a Job, other than Job 0, to load files which include system extensions (i.e. MENU_REXT, QTYP etc.).

No mention of what happens after NEW there.
Did a quick scan through Wolfgang's reference manual, didn't find anything there. Not looked in SMSQ/E sources.
If we can clarify this is correct, I could update the SBASIC manual.

And it wouldn't hurt if you don't as it apparently didn't bother anyone for the last 20 years.....

(It escapes my why someone would want to load SBASIC extensions into a daughter BASIC only - It maybe makes sense when you're developing an extension, but in "normal operation" it is likely just a good method to intensely confuse yourself)