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