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.