martyn_hill wrote:If I may return to one of the original questions very briefly - "Must we pre-load a1 with bv_rip(a6) BEFORE calling CHRIX/RESRI?", can we agree that this step is unnecessary (contrary to the SMSQ reference guide and source code comments)?
Well, if you didn't change a1 from its previous value, there is not much point in saving the maths stack pointer in BV_RIP(a6). If you did, however (which means BV_RIP(a6) doesn't really contain what it should), you should update the basic variable.
The routine you're looking for is sb_resar in smsq_sbas_ressb_asm. It doesn't even use a1 as a parameter or return value, so there is not much point in setting it. a1 is also returned unchanged from there. The maths stack to be grown is retrieved from and returned in BV_RIP(a6).
The original Technical guide doesn't say anything about what the value in a1 should be when entering BV.CHRIX, neither does it say it's set to any specific value on return. The SMSQ reference guide wants it set to the value of BV_RIP(a6), which I think is irritating - After looking at the code, I think that's unnecessary (but won't hurt, as the routine will still take the value from the variable).
If you think about it, it makes some sense: The pointer to the maths stack points to somewhere inside a memory block, the user doesn't know exactly where relative to the start of that block - That's not very useful for the purpose of expanding that block. The system needs to know the start and length of the block in order to grow or shrink (and thus, in a lot of cases, move) it. The system holds that block start in sb_arthb(a6) (note the "b" for "base" instead of "p" for "pointer"). The only use a1 could have for that purpose is that the pointer needs to be adjusted after the block has been moved in order to let it point to the same entries - and BV_RIP/sb_arthp(a6) needs to be adjusted anyways, so the system is only doing that and you have to pick your new stack top from there after the move.