Correct Maths Stack usage (CHRIX/RESRI)

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by tofro »

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.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by pjw »

tofro wrote: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 sb_resar call can follow many different paths depending on circumstances. Did you check them all? One of those paths ends up in the main interpreter loop, where a1 is expected to point to the ri stack. I got lost in the tangle, so am not sure whether that could be the reason for the new requirement given for qa.resri.
It would be interesting to find out, however, as this requirement would make a lot of old code "incompatible", although any new code wont cause any problem if the new requirement turns out to have been a mistake.


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by pjw »

Also the new error return paradigm could cause a problem for old code that doesnt expect one..


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by tofro »

pjw wrote:
tofro wrote: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 sb_resar call can follow many different paths depending on circumstances. Did you check them all? One of those paths ends up in the main interpreter loop, where a1 is expected to point to the ri stack. I got lost in the tangle, so am not sure whether that could be the reason for the new requirement given for qa.resri.
It would be interesting to find out, however, as this requirement would make a lot of old code "incompatible", although any new code wont cause any problem if the new requirement turns out to have been a mistake.
Per,

That file handles all the SB heaps, so contains a lot of stuff. But entering through sb_resar is pretty straightforward and doesn't have any branches (other than a "do nothing" exit if the wanted space is already there or the routine not being called from SBASIc context). I can't see a1 used as a parameter or return value anywhere in there. It's moved to the stack unchanged and retrieved before return - I think that's simple enough ;)

The path that ends up in the main interpreter loop is entered only if sms.achp fails (so that's probably "insufficient memory", and cleans up all of SBASIC. Thus, I can't see as well why this routine should ever return with an error to the caller - I think it doesn't.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by pjw »

tofro wrote:That file handles all the SB heaps, so contains a lot of stuff. But entering through sb_resar is pretty straightforward and doesn't have any branches (other than a "do nothing" exit if the wanted space is already there or the routine not being called from SBASIc context).
Sorry to contradict you, but here is one possible path from sb_resar:
sb_resar
sbr_dn
sbr_alldn
sb_insmem
sb_istop
sis_arth
sis_clean
sis_rteasp -> destroys a1
I haven been able to follow them all. What Im trying to do is find out whether there is a reason for the documented requirement in question. If there is not (which I hope is the case), it should be corrected. If there is, many old toolkits may throw up strange and possibly hard-to-detect errors and we're all fcuked. (Sorry for bringing football into this)


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by tofro »

pjw wrote:
tofro wrote:That file handles all the SB heaps, so contains a lot of stuff. But entering through sb_resar is pretty straightforward and doesn't have any branches (other than a "do nothing" exit if the wanted space is already there or the routine not being called from SBASIc context).
Sorry to contradict you, but here is one possible path from sb_resar:
sb_resar
sbr_dn
sbr_alldn
sb_insmem
sb_istop
sis_arth
sis_clean
sis_rteasp -> destroys a1
I haven been able to follow them all. What Im trying to do is find out whether there is a reason for the documented requirement in question. If there is not (which I hope is the case), it should be corrected. If there is, many old toolkits may throw up strange and possibly hard-to-detect errors and we're all fcuked. (Sorry for bringing football into this)
I'm not feeling contradicted - That's the path I mentioned above which is taken when sms.alchp for the bigger stack fails - The code never returns to the caller from there but rather stops the BASIC program with an "out of memory error". No reason to bother with it. (Note the stack is trashed anyhow when getting there). That is also why I think the BV.CHRIX vector is not made to ever return an error code (contrary to the SMSQ/E docs, but in line with what the Technical Guide says). It either succeeds or stops the interpreter (and re-initializes a lot of internal structures, including the RI stack).

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by pjw »

tofro wrote:I'm not feeling contradicted - That's the path I mentioned above which is taken when sms.alchp for the bigger stack fails - The code never returns to the caller from there but rather stops the BASIC program with an "out of memory error". No reason to bother with it. (Note the stack is trashed anyhow when getting there). That is also why I think the BV.CHRIX vector is not made to ever return an error code (contrary to the SMSQ/E docs, but in line with what the Technical Guide says). It either succeeds or stops the interpreter (and re-initializes a lot of internal structures, including the RI stack).
It makes total sense, so if that is the final verdict here, the scare is over and we can all go back to sleep :) I shall pass a note to ql-users that the info on qa.resri is incorrect. If I get into a fight with anyone there, Ill refer them to you ;)


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Correct Maths Stack usage (CHRIX/RESRI)

Post by tofro »

I have checked my paper copy of the SMSQ/E Reference Manual (from 1992, when you still had to buy it...) - It has the very same information, which I still strongly believe is wrong.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply