The Sinclair QL Forum

Having a blank moment writing a BASIC extension.

Need to reserve space for a string on the RI stack and can't remember if the allocation of space on the stack using bv.chrix (vector $11A) should always be an even value or not?

Probably a bug elsewhere in my extension, seems to be going wrong with odd length strings, so I don't know if this is a red herring or not. The guides seem to make no mention of a requirement for the allocation to be an even number, for what it's worth.

Hi Dilwyn,

Not sure I have the right answer, I looked in the Technical guide pg.50.

A string is stored as a word character count, followed by the characters of the
string. The string storage always takes a multiple of two bytes.

I realised strings may have to be aligned on even boundary as I once tested UT.CSTR utility function, it only works for strings with even alignment and padding.

Tom

What you are actually looking for ist the paragraph on page 55:

Note that strings must be aligned on the arithmetic stack so that the character count is on a word boundary. All entries on the stack must be a multiple of two bytes long, so that a string of odd length has one byte at the end which contains no information

Allocating an odd length as such is not explicitly forbidden. As (a6,a1) points to the end, though, I would guess all of your stack could end up unaligned. (allocating an odd length would, however, not make a lot of sense, because you would never be able to use the last byte anyhow.)

Defining an odd length data space for a job is not forbidden as well by the manuals - But makes the QL crash anyhow

Tobias

Dilwyn,

Have a gander at DJTOOLKIT source. There is a need to keep a6,a1 even so asking for an odd allocation will most likely work, but when you return to SuperBasic, it will most likely crash.

I'm sure I read somewhere that you should always allocate an even number of bytes on the stack, so I've always tried to do that.

HTH

Cheers,
Norm.

Hi Dilwyn,

There is no need to round BV.CHRIX requests to an even value since it will always be rounded up to the nearest multiple of 16 bytes (JS) or 64 bytes (Minerva). This mechanism is explained in the Minerva manual and source code (see bv\chstk.asm).

That said, strings on the RI stack should of course be word aligned since they start with a word containing its length. What I always did was take the length of the string, add 3 (2 for length word + possible padding byte) and then clear bit 0 which yields the total amount of bytes required on the stack, which will always be even.

regards, Jan.

janbredenbeek wrote:Hi Dilwyn,

There is no need to round BV.CHRIX requests to an even value since it will always be rounded up to the nearest multiple of 16 bytes (JS) or 64 bytes (Minerva). This mechanism is explained in the Minerva manual and source code (see bv\chstk.asm).

That said, strings on the RI stack should of course be word aligned since they start with a word containing its length. What I always did was take the length of the string, add 3 (2 for length word + possible padding byte) and then clear bit 0 which yields the total amount of bytes required on the stack, which will always be even.

regards, Jan.

Thank you Jan. As it happens, the problem was elsewhere in the code, as I had ensured the stack space allocated was even "just in case". Took me a long time to work out what I'd done wrong though (like many such silly typo mistakes).