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.