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
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.
Minerva, apparently, returns D0 = 0 on a successful return (because
QLib requires it according to one source?) but for the other OSes it
is undefined. (I dont doubt that Minerva does so, but that QLib should
require it is news to me..)
As for BV_RIP (aka sb_arthp), my understanding is that if you have
information on the stack prior to this call, that you wish to keep,
you do need to set BV_RIP to point to it. Example:
get three longs
do stuff..
; you want to keep the first long on the stack and loose the rest
addq.l #8,A1 ; A1 -> long on stack
do some more..
; now you want ten more bytes, but dont want to loose the long, so you
move.l A1,BV_RIP(A6)
moveq #10,d1 ; request 10 bytes (but in effect
you only want two more)
to save or not save A1 here, that is the question.. (SMSQ/E
appears to preserve it)
move.w BV.CHRIX,A2
jsr (A2)
; dont bother testing D0 here.. (SMSQ/E appears to set D0 to 0, but
not JS)
sub.l #10,BV_RIP(A6) ; grab the extra ten bytes
move.l BV_RIP(A6),A2 ; A2 -> 10 (+ 4) bytes on stack
do stuff here..
; say you want to return a word integer to BASIC
lea.l 12(A2),A1 ; add the difference and put into A1
move.l A1,BV_RIP(A6)
move.w Dx,(A6,A1.l) ; put your return value on the stack
now return int to BASIC
What we still dont know for sure is if A1 is preserved after the call
in all variants of the OS.
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
2) Is D0 set to 0 after BV_CHRIX?: JS: No. Minerva & SMSQ/E: Yes
3) Are items on the stack preserved after BV_CHRIX (as described
above)?: JS, Minerva & SMSQ/E: Yes
Incidentally, running the test in various typical configurations to
test stack leakage showed it to be copper bottomed; ie, no leaks.
Obviously, these are limited tests as I cannot create the environment
to challenge every case, so it will be down to the code peekers to
make any final determination. If anyone wants my code to test on AH
and other exotica, you know where I live..
Per
On 15/02/2018 05:08, Wolf via Ql-Users wrote:
Hi,
thanks, Per, for pointing out the inconsistencies in the entry
conditions in vector QA.RESRI.
I'll make a note in the next version of the "QDOS SMS Reference
guide" (ex Technical Manual and ex QDOS SMS reference manual) that
on SMSQ/E it is not necessary to save the stack pointer in
BV_RIP(A6) before calling this vector. However, I'm going to leave
the general requirement in, since I don't know how this is handled
in QDOS (AH, JM, JS etc), or in Minerva.
Wolfgang
_______________________________________________
QL-Users Mailing List
_______________________________________________
QL-Users Mailing List
