On 8 June 2018 at 15:52, pjwitte via Ql-Users <ql-users@lists.q-v-d.com>

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

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


(I hope the assembly listing is readable, I copy-pasted them from GitHub).

*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
QL-Users Mailing List

Reply via email to