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.


QL-Users Mailing List

Reply via email to