> Am 16.02.2018 um 10:27 schrieb Jan Bredenbeek via Ql-Users 
> <ql-users@lists.q-v-d.com>:
> 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.


QL-Users Mailing List

Reply via email to