Re: [Ql-Users] A polite request
Evening Per, On 15/02/18 17:42, pjwitte via Ql-Users wrote: For my part, I believe Ive apologised very handsomely for the error of my ways (although any forgiveness still seems to be working its way though my accuser's brain) so I have no more to give on this and require no further instruction. Look back up the thread, you were forgiven. Not that you needed forgiving, other people do it too. It's a minor irritation and certainly not something to lose sleep over. Nor will I take kindly to any further reprimand on the topic. There is plenty one could moan about on this list if one were thus inclined. Nuff said. Oh, I would tend to disagree there. Respectfully disagree of course. I think this is one of the better lists I enjoy reading - even when the subject has little or no interest for me - and responding to as and when appropriate. We are a pretty friendly bunch on here, in my opinion. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
On 15/02/2018 18:42, pjwitte via Ql-Users wrote: move.w qa.resri,d0 moveq #0,d0 jsr (a2) tst.l d0 Err, that should be move.w qa.resri,a2, but I guess that's pretty obvious. The next bit isnt obvious, but is correct. Per ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
Neet to reprase my below statement: > Am 15.02.2018 um 16:26 schrieb Tobias.Froeschle--- via Ql-Users > : > > 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" > An: "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 Mail
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
On 15/02/2018 14:46, Wolfgang Lenerz via Ql-Users wrote: <> Thanks for testing these. How big was the amount of memory requested? Big enough that a shift would occur? Yes. Further tests show that d0 sometimes returns zero (at least two different paths) but usually not, ie it returns with the pre-call value intact. If insufficient memory, it returns to BASIC. In other words, to get a reliable error result, one would have to: move.w qa.resri,d0 moveq #0,d0 jsr (a2) tst.l d0 This is obviously not ideal.. I havent done any tests with either compiler, but Ive already lost two hours of my life I'll never get back, so if someone else wants to have a go, I promise to read - and cherish - the results :) Per ___ QL-Users Mailing List
Re: [Ql-Users] A polite request
On 15/02/2018 14:32, Marcos Cruz via Ql-Users wrote: En/Je/On 2018-02-14 19:40, Norman Dunbar via Ql-Users escribió / skribis / wrote : Please, please, please do not "hijack" a thread. Don't reply to a thread and change the subject to something completely unrelated. I agree. That is important. I support your request. <> For my part, I believe Ive apologised very handsomely for the error of my ways (although any forgiveness still seems to be working its way though my accuser's brain) so I have no more to give on this and require no further instruction. Nor will I take kindly to any further reprimand on the topic. There is plenty one could moan about on this list if one were thus inclined. Nuff said. Per ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
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" An: "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
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
On 15 February 2018 at 11:45, pjwitte via Ql-Users wrote: > 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 > Correct as far as I can see. > 2) Is D0 set to 0 after BV_CHRIX?: JS: No. Minerva & SMSQ/E: Yes > Correct. I've done a short test on SMSQmulator to see if it does return from an 'out of memory' condition (assumed it has no more than 16 MB available): result dc.l 0 move.l #16*1024*1024,D1 move.w $11a,a2 jsr (a2) lea result(pc),a1 move.l d0,(a1) moveq#0,d0 rts When I LBYTES this followed by CALL A+4, I get 'insufficient memory'. The long word at 'result' was still zero afterwards. So it doesn't return when an error occurs (unlike other claims). > 3) Are items on the stack preserved after BV_CHRIX (as described above)?: > JS, Minerva & SMSQ/E: Yes > Yes, but don't forget to set BV.RIP(A6) to current TOS beforehand. The Minerva doc says that only the active part of any area is moved (unlike JS). So anything below BV.RIP(A6) that is still part of the RI stack area will not be moved (and probably overwritten). Jan. -- *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
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
Re: [Ql-Users] A polite request
En/Je/On 2018-02-14 19:40, Norman Dunbar via Ql-Users escribió / skribis / wrote : > Please, please, please do not "hijack" a thread. Don't reply to a > thread and change the subject to something completely unrelated. I agree. That is important. I support your request. Some times, email users _reply_ to whatever message they are reading, change the subject and write a message on a totally different topic... That makes some things more difficult for others, especially on email lists. All email messages have a metadatum in its header containing the unique identifier of the replied email, if any. That is how email clients can sort messages hierarchicaly. The problem is some web-mail services (including Gmail), or even some "actual" email clients, thread messages _also_ by the subject line... I guess that's why some users are not aware of the problem. But threading by subject line is a cosmetic trick: the real link between messages is still there, in their internal header. Of course, sometimes it's necessary to change the subject in the middle of a thread, but only when the conversation _naturally_ leads to a different topic. In those cases, the change helps to identify the topic branches in the hierarchy. And there's a convention for that: Subject: Re: Original topic Subject: Modified topic (Was: Re: Original topic) Hope this helps. > If you start a new thread by replying to another, and change the > subject, your threaded topic ends up hidden within the original topic Exactly. -- Marcos Cruz http://programandala.net ___ QL-Users Mailing List
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
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
Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide
Hmm. Are we sure about that? 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). Tobias > Am 15.02.2018 um 05:08 schrieb Wolf via Ql-Users : > > 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
