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 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 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 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 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 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
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
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
