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