Re: [Ql-Users] QA.RESRI info incorrect
Hi Per, yes I misquoted myself. On SMSQ/E it is not necessary for A1 to contain the ARI stack pointer before calling this vector. Regards Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
Great, Wolfgang! But surely, if you have something on the stack youd like to keep, you still need to save the stack pointer, otherwise how will the system know? Per On 09/06/2018 06:50, Wolf via Ql-Users wrote: Hi, I'll amend the documentation. I will also mention that this vector, under SMSQ/E, simply does nothing when called from a compiled program. I already added a note that under SMSQ/E it is not necessary to save the stack pointer in BV_RIP(A6) before calling this vector. There are also other additions/corrections to the documentaton. I'll release the new doc either today or tomorrow. Wolfgang On 08/06/2018 19:29, pjwitte via Ql-Users wrote: Having gone through it all again, Ive come to the conclusion that the bugs are in the documentation! This is what it should look like: ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: none In other words, in the case of insufficient memory this routine returns to a higher level; it never comes back here. There is no need, in fact it is a mistake, to test d0 on return from this routine. If anyone knows otherwise then please let ut know! Per ___ QL-Users Mailing List ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
Hi, I'll amend the documentation. I will also mention that this vector, under SMSQ/E, simply does nothing when called from a compiled program. I already added a note that under SMSQ/E it is not necessary to save the stack pointer in BV_RIP(A6) before calling this vector. There are also other additions/corrections to the documentaton. I'll release the new doc either today or tomorrow. Wolfgang On 08/06/2018 19:29, pjwitte via Ql-Users wrote: Having gone through it all again, Ive come to the conclusion that the bugs are in the documentation! This is what it should look like: ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: none In other words, in the case of insufficient memory this routine returns to a higher level; it never comes back here. There is no need, in fact it is a mistake, to test d0 on return from this routine. If anyone knows otherwise then please let ut know! Per ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
Having gone through it all again, Ive come to the conclusion that the bugs are in the documentation! This is what it should look like: ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: none In other words, in the case of insufficient memory this routine returns to a higher level; it never comes back here. There is no need, in fact it is a mistake, to test d0 on return from this routine. If anyone knows otherwise then please let ut know! Per ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 08/06/2018 17:16, Jan Bredenbeek via Ql-Users wrote: On 8 June 2018 at 15:52, pjwitte via Ql-Users wrote: When loading this into RESPR and then doing CALL base+4 I get an 'insufficient memory' error. But PEEK_L(base) returns 0 so the code never got to the point where it stores the result. Sure, but this is not the whole story. For example when I ran your code just now in a daughter SBASIC, with no free memory, it returns ok, but peeking result I get an err.ipar! Depending on circumstances, there are a number of possible paths this routine can take. From my own investigations (I wish Id written up what I did, not only the conclusion!) in some cases this routine forgets to set error code on a successful return. Well the source code starts in https://github.com/SinclairQL/SMSQE/blob/master/smsq/sbas/ressb_asm at line 40 (actual entry point at line 46): ;+++ ; reserve stage posts SuperBASIC d1 bytes (optional), d1/d2/d3 smashed ;--- sbs_rar32 moveq #32,d1 ; the order of these instructions ; ; is critical for compatibility moveq #sb_arthp,d2 ; with some QL software bra.s sbs_dn Then it jumps via a long jump to sbr_dn: sbr_dn cmp.l #sb.flag,sb_flag(a6) ; SBASIC? bne.s sbr_nop sub.l 0(a6,d2.l),d1 ; -(pointer - required) add.l sb.loffp(a6,d2.l),d1 ; lower limit -(pointer - required) bgt.s sbr_alldn or it returned here rts .. sbr_nop rts Somehow the test for SBASIC at sb_flag(a6) failed and the routine returned at sbr_nop, leaving D0 unmodified. Since on entry to a CALLed routine it contains -15 (err.ipar), this is probably what happened. Strange enough, when I tested this on a SBASIC daughter job, I got the same result as before ('insufficient memory', no normal return), even when running the commands in a program. So when does the test for sb.flag at sb_flag(a6) fail? I think it's probably a test for compiled (i.e. Qliberated or Turbo'ed) SBASIC? or on this trajectory in the same file, ie via sbr_rtr, which would also not set D0. sbr_retb cmp.la6,a0; allocation in SBASIC? blo.ssbr_retdo; ... no cmp.lsp,a0 blo.ssbr_rtr ; ... yes, do not return it sbr_retdo moveq#sms.rchp,d0 trap #do.sms2 sbr_rtr movem.l (sp)+,sbra.rgx sbr_rts rts (Taken from the official sources and always reads ok ;) Jan. (I hope the assembly listing is readable, I copy-pasted them from GitHub). ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 8 June 2018 at 15:52, pjwitte via Ql-Users wrote: > When loading this into RESPR and then doing CALL base+4 I get an >> 'insufficient memory' error. But PEEK_L(base) returns 0 so the code never >> got to the point where it stores the result. >> > Sure, but this is not the whole story. For example when I ran your code > just now in a daughter SBASIC, with no free memory, it returns ok, but > peeking result I get an err.ipar! > Depending on circumstances, there are a number of possible paths this > routine can take. From my own investigations (I wish Id written up what I > did, not only the conclusion!) in some cases this routine forgets to set > error code on a successful return. Well the source code starts in https://github.com/SinclairQL/SMSQE/blob/master/smsq/sbas/ressb_asm at line 40 (actual entry point at line 46): ;+++ ; reserve stage posts SuperBASIC d1 bytes (optional), d1/d2/d3 smashed ;--- sbs_rar32 moveq #32,d1 ; the order of these instructions ; ; is critical for compatibility moveq #sb_arthp,d2 ; with some QL software bra.s sbs_dn Then it jumps via a long jump to sbr_dn: sbr_dn cmp.l #sb.flag,sb_flag(a6) ; SBASIC? bne.s sbr_nop sub.l 0(a6,d2.l),d1 ; -(pointer - required) add.l sb.loffp(a6,d2.l),d1 ; lower limit -(pointer - required) bgt.s sbr_alldn rts .. sbr_nop rts Somehow the test for SBASIC at sb_flag(a6) failed and the routine returned at sbr_nop, leaving D0 unmodified. Since on entry to a CALLed routine it contains -15 (err.ipar), this is probably what happened. Strange enough, when I tested this on a SBASIC daughter job, I got the same result as before ('insufficient memory', no normal return), even when running the commands in a program. So when does the test for sb.flag at sb_flag(a6) fail? I think it's probably a test for compiled (i.e. Qliberated or Turbo'ed) SBASIC? Jan. (I hope the assembly listing is readable, I copy-pasted them from GitHub). -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 08/06/2018 14:29, Jan Bredenbeek via Ql-Users wrote: On 8 June 2018 at 13:26, pjwitte via Ql-Users wrote: It appears that, on an error, QDOS doesnt return here at all! Correct. Under SMSQ/E it may return an error (IMEM), but the error code is not always set! That implies that you could get a wrong result, depending on what was in D0 before the call. I've tested this earlier using this code on SMSQmulator: result dc.l 0 move.l #16*1024*1024,D1 move.w $11a,a2 jsr (a2) lea result(pc),a1 move.l d0,(a1) moveq#0,d0 rts When loading this into RESPR and then doing CALL base+4 I get an 'insufficient memory' error. But PEEK_L(base) returns 0 so the code never got to the point where it stores the result. Sure, but this is not the whole story. For example when I ran your code just now in a daughter SBASIC, with no free memory, it returns ok, but peeking result I get an err.ipar! Depending on circumstances, there are a number of possible paths this routine can take. From my own investigations (I wish Id written up what I did, not only the conclusion!) in some cases this routine forgets to set error code on a successful return. Per ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 8 June 2018 at 13:26, pjwitte via Ql-Users wrote: It appears that, on an error, QDOS doesnt return here at all! > Correct. > Under SMSQ/E it may return an error (IMEM), but the error code is not > always set! That implies that you could get a wrong result, depending on > what was in D0 before the call. > I've tested this earlier using this code on SMSQmulator: result dc.l 0 move.l #16*1024*1024,D1 move.w $11a,a2 jsr (a2) lea result(pc),a1 move.l d0,(a1) moveq#0,d0 rts When loading this into RESPR and then doing CALL base+4 I get an 'insufficient memory' error. But PEEK_L(base) returns 0 so the code never got to the point where it stores the result. Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 08/06/2018 12:20, gdgqler--- via Ql-Users wrote: On 14 Feb 2018, at 13:49, pjwitte via Ql-Users wrote: |In later versions of the QDOS and SMSQ/E Reference Manual the documentation on QA.RESRI (aka bv.chrix), to test or stretch the arithmetic stack states: Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 Pointer to RI stack (rel. A6) A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: IMEM out of memory [SMSQ] none [QDOS] This is strongly suspected to be incorrect. It should say the following (two corrections): ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: none D0 returns the error code under SMSQ but is corrupted under QDOS It appears that, on an error, QDOS doesnt return here at all! Under SMSQ/E it may return an error (IMEM), but the error code is not always set! That implies that you could get a wrong result, depending on what was in D0 before the call. To my mind, SMSQ/E should behave the same way as QDOS in this instance, as many old toolkits will not test the error code, assuming that if the call returns, it implies there was no error. In other words, IMHO, SMSQ/E's behaviour here is a BUG. Per ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
> On 14 Feb 2018, at 13:49, pjwitte via Ql-Users > wrote: > > |In later versions of the QDOS and SMSQ/E Reference Manual the documentation > on QA.RESRI (aka bv.chrix), to test or stretch the arithmetic stack states: > > Vector $11A Reserve Room on Arithmetic Stack QA.RESRI > Call parameters Return parameters > D1.L Number of bytes required D1 ??? > D2 D2.L ??? > D3 D3.L ??? > A0 A0 Preserved > A1 Pointer to RI stack (rel. A6) A1 ??? > A2 A2 Preserved > A3 A3 Preserved > Error returns: > IMEM out of memory [SMSQ] > none [QDOS] > > This is strongly suspected to be incorrect. It should say the following (two > corrections): > > ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI > Call parameters Return parameters > D1.L Number of bytes required D1 ??? > D2 D2.L ??? > D3 D3.L ??? > A0 A0 Preserved > A1 A1 ??? > A2 A2 Preserved > A3 A3 Preserved > Error returns: none D0 returns the error code under SMSQ but is corrupted under QDOS George ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
pjwitte via Ql-Users wrote: > On 14/02/2018 15:04, Marcel Kilgus via Ql-Users wrote: >> pjwitte via Ql-Users wrote: >>> Error returns: >>> IMEM out of memory [SMSQ] >> This is correct. > If this is correct, isnt that bad news for any old toolkits that dont > expect the call to return on IMEM (as per the original Technical > Guide)? They would assume the memory is there and poke a hole in it.. Yes, actually I might be wrong here, looks like it tries to abandon the current command in this case. >>> Error returns: none >> This is not ;-) > You are certain of this? Nah, for me nothing is certain in SBasic ;-) By the way, if you look at the Minerva code you see retzero moveq #0,d0 this was silly, but Qlib expected it! rts Marcel ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
On 14/02/2018 15:04, Marcel Kilgus via Ql-Users wrote: pjwitte via Ql-Users wrote: Error returns: IMEM out of memory [SMSQ] This is correct. If this is correct, isnt that bad news for any old toolkits that dont expect the call to return on IMEM (as per the original Technical Guide)? They would assume the memory is there and poke a hole in it.. A1 A1 ??? This is probably correct. Error returns: none This is not ;-) You are certain of this? Some of us have tried to follow some of the many paths this routine could take, and at least in some instances it appears to actually return to BASIC directly. So are you saying that in some instances it dosnt? ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI info incorrect
pjwitte via Ql-Users wrote: > Error returns: > IMEM out of memory [SMSQ] This is correct. > A1 A1 ??? This is probably correct. > Error returns: none This is not ;-) Marcel ___ QL-Users Mailing List
[Ql-Users] QA.RESRI info incorrect
|In later versions of the QDOS and SMSQ/E Reference Manual the documentation on QA.RESRI (aka bv.chrix), to test or stretch the arithmetic stack states: Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 Pointer to RI stack (rel. A6) A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: IMEM out of memory [SMSQ] none [QDOS] This is strongly suspected to be incorrect. It should say the following (two corrections): ||Vector $11A Reserve Room on Arithmetic Stack QA.RESRI Call parameters Return parameters D1.L Number of bytes required D1 ??? D2 D2.L ??? D3 D3.L ??? A0 A0 Preserved A1 A1 ??? A2 A2 Preserved A3 A3 Preserved Error returns: none Please complain if you know otherwise, or correct your notes, as appropriate Per ||| ___ QL-Users Mailing List