Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

On 16/02/2018 22:12, pjwitte via Ql-Users wrote:
<>
If Ive understood correctly, SBASIC sets up each array in its own 
heap. This assumption was partially or wholly incorrect. Sorry. I'll shut up 

now.

P
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

On 16/02/2018 12:50, pjwitte via Ql-Users wrote:

On 16/02/2018 10:27, Jan Bredenbeek via Ql-Users wrote:

<>
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.



I made a quick test today regarding what I stated above about QLib:

10 ch = FOPEN('con')
11 m = FREE_MEM
12 DIM a$(32000, 200)
13 PRINT#ch; HEX$(m - FREE_MEM, 32)
14 PAUSE#ch

I compiled it with QLib; dataspace 3.5Kb. It proves that QLib reserves 
memory in the CHP rather than being bound within its dataspace. Some 
470 bytes additional to the array+descriptor requirements were taken, 
so whether it performs the same stunt as SBASIC and creates a whole 
new name table/name list area once it outgrows an old one, or just 
reserves room for the array and some extra, is not revealed by this 
simple test.
I seem to recall, back in the mists of time, that QLib (or was it 
SuperCharge?) had this restriction: Everything had to fit within the 
dataspace; if you DIMed large arrays etc, you needed to increase your 
dataspace accordingly.
If Ive understood correctly, SBASIC sets up each array in its own 
heap. That doesnt seem to be the case with QLib, but I cant say for sure..

P

___
QL-Users Mailing List

Re: [Ql-Users] A polite request

[pjwitte via Ql-Users]

On 15/02/2018 21:07, Norman Dunbar via Ql-Users wrote:
<> There is plenty one could moan about on this list if one were 
thus inclined. Nuff said.


Oh, I would tend to disagree there. Respectfully disagree of course. 
I think this is one of the better lists I enjoy reading - even when 
the subject has little or no interest for me - and responding to as 
and when appropriate. 
I was thinking more of how (physically) messy it sometimes gets. The 
excuses I make for others in such instances is that it may have to do 
with how familiar they are with evolving vagaries of their various 
email clients. When Im forced to use Google's webmail interface, I 
have no idea what the result looks like for anyone else. It tries too 
hard to be helpful in doing stuff I just dont want done! Ive had the 
extreme annoyance and embarassment of accidentally forwarding 
information sent by one party to another that wasnt supposed to see 
that information. This despite the efforts I made to ensure it didnt 
happen. The only upside to such potential calamity is that other 
people do it too, and so one may acquire useful information one was 
not supposed to have ;)


Per
___
QL-Users Mailing List

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[pjwitte via Ql-Users]

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

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Tobias Fröschle via Ql-Users]

> 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 <
> 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

Re: [Ql-Users] QA.RESRI - QDOSMSQ eference guide

[Jan Bredenbeek via Ql-Users]

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.

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).

Does anyone have a clue?

regards,

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List