Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

On 16/02/2018 22:12, pjwitte via Ql-Users wrote:
<>
If Ive understood correctly, SBASIC sets up each array in its own 
heap. This assumption was partially or wholly incorrect. Sorry. I'll shut up 

now.

P
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

On 16/02/2018 12:50, pjwitte via Ql-Users wrote:

On 16/02/2018 10:27, Jan Bredenbeek via Ql-Users wrote:

<>
SBASIC bahaves in much the same way as QLiberated programs. I guess 
QLib has always used the Common Heap for its names and variables, as 
SBASIC does now. Also a6 is fixed under both models (and Turbo); the 
only reason to double index references is where it is necessary to 
maintain compatibility with SuperBASIC.



I made a quick test today regarding what I stated above about QLib:

10 ch = FOPEN('con')
11 m = FREE_MEM
12 DIM a$(32000, 200)
13 PRINT#ch; HEX$(m - FREE_MEM, 32)
14 PAUSE#ch

I compiled it with QLib; dataspace 3.5Kb. It proves that QLib reserves 
memory in the CHP rather than being bound within its dataspace. Some 
470 bytes additional to the array+descriptor requirements were taken, 
so whether it performs the same stunt as SBASIC and creates a whole 
new name table/name list area once it outgrows an old one, or just 
reserves room for the array and some extra, is not revealed by this 
simple test.
I seem to recall, back in the mists of time, that QLib (or was it 
SuperCharge?) had this restriction: Everything had to fit within the 
dataspace; if you DIMed large arrays etc, you needed to increase your 
dataspace accordingly.
If Ive understood correctly, SBASIC sets up each array in its own 
heap. That doesnt seem to be the case with QLib, but I cant say for sure..

P

___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

On 16/02/2018 10:27, Jan Bredenbeek via Ql-Users wrote:

<>
What puzzles me however is that, in case more space from the system is
needed, this is done using a call to sms.achp (mt.alchp) rather than
mt.albas. So the extra space seems to be allocated in the Common Heap
rather than the S*BASIC area. Now I know that SMSQ/E has a memory
allocation scheme that's different from good old QDOS in some respects, but
I'm curious about the rationale behind this. When space for the RI stack
(or any other S*BASIC area for that matter) is allocated from the Common
Heap, there would be no problem extending this to compiled programs
(assuming they won't expect their data to be somewhere in the TRNSP area).
SBASIC is very different from SuperBASIC. It uses a fixed memory 
model. Different parts of each instance of SBASIC live in their own 
areas. Only the bit that is called  the SuperBASIC Stub - which is a 
minimalist version of the old SuperBASIC area - is movable in the old 
sense, and subject to expansion or contraction by the now emulated 
MT.ALBAS/REBAS traps. The Stub is only there for reasons of 
compatibility with a small subset of once popular - and now 
unnecessary - programs.


SBASIC name tables and name lists reside in the Common Heap. When 
these need to expand, new areas are allocated in the common heap, and 
the necessary bits are moved over, and pointers adjusted accordingly. 
Each SBASIC has its own local name table/list, but there is also a 
global name table from which entries may be copied during parsing.


SBASIC bahaves in much the same way as QLiberated programs. I guess 
QLib has always used the Common Heap for its names and variables, as 
SBASIC does now. Also a6 is fixed under both models (and Turbo); the 
only reason to double index references is where it is necessary to 
maintain compatibility with SuperBASIC.


There is relatively detailed documentation floating about, but, for 
some reason, it isnt easy to find.


Per


___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Tobias Fröschle via Ql-Users]

> Am 16.02.2018 um 10:27 schrieb Jan Bredenbeek via Ql-Users 
> :
> 
> On 15 February 2018 at 19:33, Tobias Fröschle via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
> 
>>> 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
> 
> 
> At least it could exit when an 'out of memory' situation occurs, rather
> than let the program continue assuming there's enough space where in fact
> there isn't.

Without some (valid or invalid) assumptions on how the compiler allocates space 
and where it stores the pointers, I'm afraid that would be a bit difficult. 
While I think it would be relatively safe to assume the compiler runtimes 
replicate the BV_RIP and BV_RIBAS variables that hold the current RI top and 
the base address of the RI stack. That pointers, however, could point to a 
dedicated heap block for the RI stack or just to somewhere in the compiled 
task's data space - trying to reallocate that would probably have varying 
results - Fiddling with a task's memory is apparently something that TT rather 
refrained from and said "I'd rather not care".

> 
> What puzzles me however is that, in case more space from the system is
> needed, this is done using a call to sms.achp (mt.alchp) rather than
> mt.albas. So the extra space seems to be allocated in the Common Heap
> rather than the S*BASIC area. Now I know that SMSQ/E has a memory
> allocation scheme that's different from good old QDOS in some respects, but
> I'm curious about the rationale behind this. When space for the RI stack
> (or any other S*BASIC area for that matter) is allocated from the Common
> Heap, there would be no problem extending this to compiled programs
> (assuming they won't expect their data to be somewhere in the TRNSP area).
> 

To my knowledge, QDOS knows TPA, CHP and SuperBASIC as memory areas - SMSQ/E 
has dropped the last one as it needs multiple of them and moved the "Program" 
part (As far as I can see, mostly pointers to expandable heap memory) into the 
TPA and the RI stack and all other areas that need to expand and shrink a lot 
to the common heap. But that's just a shoot into the dark.

The Turbo Manual mentiones some relatively strict limitations like
- Resident PROCs and FNs are not guaranteed to find more 100 bytes free on the 
Maths stack.
- BV.CHRIX cannot be relied upon to expand the RI stack as tasks have to run 
within fixed bounds

And it also supplies some code on how to check - This does, however, call 
BV.CHRIX - How this can expand the RI stack on SMSQ/E is beyond me, the job 
would need to disguise itself as SBASIC.

Tobias

___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Jan Bredenbeek via Ql-Users]

On 15 February 2018 at 19:33, Tobias Fröschle via Ql-Users <
ql-users@lists.q-v-d.com> wrote:


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


At least it could exit when an 'out of memory' situation occurs, rather
than let the program continue assuming there's enough space where in fact
there isn't.

What puzzles me however is that, in case more space from the system is
needed, this is done using a call to sms.achp (mt.alchp) rather than
mt.albas. So the extra space seems to be allocated in the Common Heap
rather than the S*BASIC area. Now I know that SMSQ/E has a memory
allocation scheme that's different from good old QDOS in some respects, but
I'm curious about the rationale behind this. When space for the RI stack
(or any other S*BASIC area for that matter) is allocated from the Common
Heap, there would be no problem extending this to compiled programs
(assuming they won't expect their data to be somewhere in the TRNSP area).

Does anyone have a clue?

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

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

[Tobias Fröschle via Ql-Users]

Neet to reprase my below statement:



> Am 15.02.2018 um 16:26 schrieb Tobias.Froeschle--- via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 
> 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" <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.
> 
>> Mi

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

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] QA.RESRI - QDOSMSQ eference guide

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

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Jan Bredenbeek via Ql-Users]

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

[Wolfgang Lenerz via Ql-Users]

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] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

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

[Tobias Fröschle via Ql-Users]

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

[Ql-Users] QA.RESRI - QDOSMSQ eference guide

[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