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
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 mode
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
> 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
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 compile
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-
; 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
>
>
&
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 th
e 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.
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
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 l
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 th
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
13 matches
Mail list logo
