> 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 <
> email@example.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
>> 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
- 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.
QL-Users Mailing List