> 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.
I think the whole thing bears further investigation, as there appears to
be doubt about other aspects too. Jan Bredenbeek, for example, suggests
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:
cmp.l #sb.flag,sb_flag(a6) ; SBASIC?
sub.l 0(a6,d2.l),d1 ; -(pointer - required)
add.l sb.loffp(a6,d2.l),d1 ; lower limit -(pointer -
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.
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
QL-Users Mailing List