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

Reply via email to