Problem with parameter to a SuperBASIC machine code extension

[ql_freak]

As you can see in the screenshot after entering the machine code function, a3 (of course relative to a6) points to the following 8 bytes (8 is length of a name table entry):

02 01 FF FF 00 00 00 20

Looks good: 02 01 is the code for a string (which I have expected).

FF FF (-1 as word, Technical Guide 9.2) indicates it's a nameless item (parameter was a literal string as 'This is a SuperBASIC string') all okay, that's what I have expected.

The second longword (last 4 bytes [00 00 00 20]) points to the SuperBASIC Variables Value area and (IMHO) should point to the string, which was passed to the function. The SB VV area is offset $28 from the BASIC variables so (IMHO):

du 20(a6,28) should point to the (QDOS) string, i.e. I expect:

00 07 41 5F 4C 61 62 65 6C 00 ([LENGTH=7 {word=2 bytes}]A_LABEL)

But as you can see in the following screenshot, that's not the case.

If I use:

du 1e(a6,28) it's OK:

 
Any hints? Is Technical Guide wrong?

[janbredenbeek]

I'm not familiar with C1mon, but I couldn't reproduce this on neither Minerva nor SMSQ/E. When I take the pointer at $28(A6) (i.e. VVBAS) and add the offset from the parameter, this takes me to the correct location (the length word, not the first character of the string).

BTW, it's not very common to manipulate parameters this way. The usual way is to call CA_GTINT/GTFP/GTSTR/GTLIN to get the value on the RI stack. The only practical use of the name table entries in A3-A5 is to see which separators were used between the parameters.

[ql_freak]

I'm not familiar with C1mon, but I couldn't reproduce this on neither Minerva nor SMSQ/E. When I take the pointer at $28(A6) (i.e. VVBAS) and add the offset from the parameter, this takes me to the correct location (the length word, not the first character of the string).

I must test it again, perhaps with the Tebby monitor. Thank you for testing.

BTW, it's not very common to manipulate parameters this way. The usual way is to call CA_GTINT/GTFP/GTSTR/GTLIN to get the value on the RI stack. The only practical use of the name table entries in A3-A5 is to see which separators were used between the parameters.

I know, I do it e.g. in my GETLINE$ and improved EDLINE$ functions this way. But the extension I want to develop must be as fast as possible (it will even than be slower than that what is possible with SuperBASIC now, but my extension will have one advantage) and the string is only be required to compare with another string. The parameter must not be altered in any way. The comparison is slow anyway in SuperBASIC as a character must (even if I would use CA.GTSTR and compare from RI-stack) be accessed via #n(a6,an.l), as SuperBASIC can move at any time (e.g. if a new job is executed while the extension is running). So I hope I can use this trick, to make the extension a little bit faster (e.g. no BV.CHRIX) necessary.

[ql_freak]

Sorry for quoting myself.

... So I hope I can use this trick, to make the extension a little bit faster (e.g. no BV.CHRIX) necessary.

Was a bad idea. I have now succeeded in fetching a string parameter without using CA.GTSTR – see here, where I have implemented a simple STRLEN%() function. I have written a small SBASIC benchmark program to test it. The version with STRLEN% is a little bit slower than the version with LEN. If you want to test it, see the attachement. The version with LEN took 18 seconds the one with my STRLEN% 22.

[ql_freak]

There were some errors in strlen_asm/_cde and also in the benchmark BASIC program. I have corrected them, especially the errors Jan mentioned in this message. Albeit the switch to supervisor mode has now been removed, the result is still the same. For the SLEN% version the result is 22 or 23 and for the LEN version it is 18.

So there is no advantage (even a disadvantage) to NOT use the CA.GT... routines to get parameters, but fetch them yourself. Please note that the STRLEN% function has just been written for this benchmark, it does not even check the parameter (or even if there is any parameter). DO NOT USE THIS FUNCTION IN PRODUCTION CODE!

Corrected versions of the programs in attachement.

[ql_freak]

I must correct myself. Fetching the string directly via the nametable->variables values area is faster than fetching it with CA.GTSTR, but not much.

I have now started to implement the missing function for my reflection toolkit and fetch the string with CA.GETSTR. To test that the fetching is correct, I (preliminary) return just the string length (the hard part must still be written), so I have now a function returning the string length with CA.GTSTR. I just changed the benchmark program to use the new function instead of LEN and now the result is:

STRLEN%: 21 seconds
Version with CA.GETSTR: 24 seconds.

The reason, why the version with LEN is faster is IMO because LEN() is a function from BASIC ROM, and so will be found much faster in the name list than my STRLEN% function, which is LRESPRed after "tons" of other SuperBASIC extensions. AFAIK names in the name list are not indexed, i.e. names loaded first will be found faster. Would be a good improvement to S(uper)BASIC, if the search for a name in the name list would be speeded up, e.g. by a separate index. I dunno if anyone is capable to do such a change to the interpreter.

[pjw]

<>

The reason, why the version with LEN is faster is IMO because LEN() is a function from BASIC ROM, and so will be found much faster in the name list than my STRLEN% function, which is LRESPRed after "tons" of other SuperBASIC extensions. AFAIK names in the name list are not indexed, i.e. names loaded first will be found faster. Would be a good improvement to S(uper)BASIC, if the search for a name in the name list would be speeded up, e.g. by a separate index. I dunno if anyone is capable to do such a change to the interpreter.

In compiled code and SBASIC the location of keywords are converted to fixed addresses in the code. So no looking through the Nametable.

[ql_freak]

In compiled code and SBASIC the location of keywords are converted to fixed addresses in the code. So no looking through the Nametable.

Do you mean the NAME LIST?

IMHO it is so to find the code for a BASIC name:

Look in Name List if the name already exists.

If not create a new entry for the name in the Name List, create a new entry in the Name Table, and set the pointer in the Name List to this new entry in the Name Table.

If the name already exists in the Name List, just change the pointer in the Name List to the new entry in the Name Table.

But I may be wrong(!).

[pjw]

In compiled code and SBASIC the location of keywords are converted to fixed addresses in the code. So no looking through the Nametable.

Do you mean the NAME LIST?
<>

The name list is only used while parsing. You can, for example, compile a program without including the names of variables (see the -NONAMES directive).

Both Qlib and SBASIC process the parsed and tokenised program further than SuperBASIC, resolving all keywords used to absolute addresses. In the case of Qlib this is done while the program initialises.

[ql_freak]

Well, compiled code is not interesting to me. My Reflection toolkit will most probably only work with interpreted S(uper)BASIC. BTW: Has anyone tried to run my reflection toolkit with compiled code (IMHO NO chance with Turbo and most probably also not even with QLiberator).

And even if it would work in compiled code, it would be useless (IMHO), as IMO none of the compilers supports the MERGE command. That's the opinion of this toolkit: You can (as e.g. in Python) MERGE (import) a library, which you can use in your program (without the need, to renumber it before; just use my "rn" C program before merging). I should work with all interpreted S(uper)BASIC progs, which do NOT use GO TO (SUB, ...).

p.s.: Just started to implement the last function, which is missing (and should NOT be needed for pure S(uper)BASIC progs!). But it is unfortunately much more complicated, than I have thought. The extended version (dunno if I will succeed) will have a possibility to port even programs with GO TO (SUB, ...).