Neet to reprase my below statement:


> Am 15.02.2018 um 16:26 schrieb Tobias.Froeschle--- via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> Wolfgang,
> 
> (For some reason, I only seem to see half of the discussion, so bear with me 
> if I repeat something that was said already)
> 
> What I meant is that to me it looks like:
> 
> QA.RESPRI takes _one_ argument, and that is the amount of memory you want to 
> grow the RI stack by in D1. 
> 
> The other "needed" argument is the current top of the RI stack and that is 
> taken from BV_RIP(a6). In case your current value of a1 is different from 
> that (because your code might have fiddled with the stack), you are expected 
> to save a1 before the call to BV_RIP(a6).
> 
> As far as I can see, the vector has three possible exit points:
> 1. Not called from an S*BASIC context: --> return with nothing done, d0 is 
> what you put in, so not meant to report an error. Not really a valid use case

This _is_ a valid use case for compiled programs - But here we should be safe 
to assume that the compiler runtime environment has some space reserved for us 
- We cannot expect QDOS/SMSQ/E to do that

> 2. Space wanted is already there --> return with nothing done, d0 is what you 
> put in, so not meant to report an error
> 3. Space successfully allocated --> return with registers smashed as in docs, 
> new RI stack pointer in BV_RIP(a6)
> 
> There's a fourth exit that is taken on the "insufficient memory" case which 
> basically stops the program and enters the main interpreter loop - never 
> returns to the caller.
> 
> Wether a1 is preserved or not is relatively irrelevant for this call: If you 
> want to have a1 point at the RI stack, you are expected to reload a1 from 
> BV_RIP(a6) after the call anyways.
> 
> The expected use of the call to me seems to be like follows:
> 
> 1. If your local value of RI stack top (a1) is different from BV_RIP(a6), 
> store it there. If not, no need to care about a1
> 2. The vector will either return to you and you can assume the space is 
> there, or it will not return. Best ignore d0, it may have a non-meaningful 
> value
> 3. Re-load a1 from BV_RIP(a6) if you want to use it as RI stack pointer, 
> because the stack might have moved
> 
> 
> Tobias
> 
> 
> -----Original-Nachricht-----
> Betreff: Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
> Datum: 2018-02-15T14:46:20+0100
> Von: "Wolfgang Lenerz via Ql-Users" <ql-users@lists.q-v-d.com>
> An: "ql-us...@q-v-d.com" <ql-us...@q-v-d.com>
> 
> Hi,
> 
> (Tobias)
> 
>> Hmm. Are we sure about that?
> 
> Sorry I'm not sure I understand. Am I sure that, as I said, on SMSQ/E it 
> is not necessary to save the stack pointer in BV_RIP(A6) before calling 
> this vector. Yes, that seems quite clear to me from the code.
> 
>> When having a glance at the code, it looked to me as SMSQ/E would not 
>> use a1 at all, but rather use BV_RIP(a6) instead for the location of
>> the RI stack (just as QDOS does).
> 
> Ok, that doesn't invalidate what I said. I don't know about Qdos, though.
> 
> 
> (Per)
>> I think the whole thing bears further investigation, as there appears to 
>> be doubt about other aspects too. Jan Bredenbeek, for example, suggests 
>> that:
>> 
>> Call parameters                         Return parameters
>> ..
>> A1                                     A1 Preserved
>> 
> 
> True for SMSQE.
> 
>> He was going to investigate the various OS sources, and perhaps is still 
>> busy doing so.. Jan..?
>> 
>> What there seems to be general agreement on,  contrary to current 
>> documentation,  is that 1) what is in A1 is irrelevant to this call, and 
>> 2) that the routine doesnt return on the only possible error: IMEM.
> 
> Errm, yes and no.
> 
> One of the relevant parts of the code is:
> 
> 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
> 
> What happens when using this from a compiled program? The BNE.S will be 
> taken, so the conditions codes will be not zero. The value in D0 will be 
> ... what '(whatever was in it when the vector as called)
> 
> Likewise, even in Basic, if there IS enough space, you'll take the rts, 
> with N set and D0 whatever it was when the vector was called...
> 
> How is handled in Qdos? I don't have a disassembly right now.
> 
>> Minerva, apparently, returns D0 = 0 on a successful return 
> 
> so does SMSQ.
> 
> 
>> 
>> Update:
>> After sribbling down the example above, I decided to "weaponise" it to 
>> test the following three premises:
>> 1) Is A1 preserved?: JS, Minerva and SMSQ/E all appear to do so
> 
> Thanks for testing these.
> 
> How big was the amount of memory requested? Big enough that a shift 
> would occur?
> 
> 
> Wolfgang
> _______________________________________________
> QL-Users Mailing List
> _______________________________________________
> QL-Users Mailing List

_______________________________________________
QL-Users Mailing List

Reply via email to