Re: [Ql-Users] QA.RESRI info incorrect

2018-06-10 Thread Wolf via Ql-Users



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

2018-06-09 Thread pjwitte via Ql-Users

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

2018-06-08 Thread Wolf via Ql-Users

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

2018-06-08 Thread pjwitte via Ql-Users
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

2018-06-08 Thread pjwitte via Ql-Users

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

2018-06-08 Thread Jan Bredenbeek via Ql-Users
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

2018-06-08 Thread pjwitte via Ql-Users

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

2018-06-08 Thread Jan Bredenbeek via Ql-Users
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

2018-06-08 Thread pjwitte via Ql-Users

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

2018-06-08 Thread gdgqler--- via Ql-Users



> 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

2018-02-14 Thread Marcel Kilgus via Ql-Users
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

2018-02-14 Thread pjwitte via Ql-Users

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

2018-02-14 Thread Marcel Kilgus via Ql-Users
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

2018-02-14 Thread pjwitte via Ql-Users
|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