> 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. Tobias _______________________________________________ QL-Users Mailing List
