Martyn Hill wrote: > My questions arose from my attempts to 'find' the SBASIC variables (and > thus the internal SB tables) by peeking directly around memory and > comparing to the results of the SB peek (\\xxx) commands. The SYSVAR > "sys_sbab" no longer appears to point to a 'real' Job0 - it dosn't, for > example, match the job table entry for Job 0 at "sys_jbtb", i.e. > peek_l(!$68!0).
I've been staring at the source code for over an hour now and it makes my head hurt ;-) But that's what I could gather: Actually what you see is that there are TWO (or more) SuperBasic variable areas. The one pointed to by sys_sbab (called SuperBasic stub) holds the global name table and is mostly there so compiled programs can still work. And then there are the actual working areas, one for each SBasic job, which are relative to the JCB. These only hold the names actually used in the respective programs. This is also why you can load a BASIC extension in Job0 and have the functions be available in all SBasic jobs (because the global name table is updated), but if you load an extension in an SBasic job, only the local name table will be updated, thus the functions are only visible there. > My suspicions arose when I peeked in to an UNLOADed job0 (from Simon G's > pre-SMSQ DIYT extentions), which did not contain any useful data at all > - it uses the sys_sbab variable to locate Job 0 and just returns a 512 > byte block regardless of what's actually loaded in to Job 0. Okay, I'm not familiar with that utility. > Yes, I have now reviewed the SMSQ/E 3.13 source files and found the > information that clarifies what I've since observed, namely that the > offset of the SBASIC variables area has been shifted from directly after > the JCB (o/s $68) as it is documented for SuperBASIC, to o/s $1e8 (== > 488 dec.) from the JCB. I found that in the file "/keys/sbasic", thus: Actually it seems that at offset $68 there is a copy of the SuperBasic stub mentioned above, to keep some old programs/extensions/compilers happy. > Again, existing documentation _appears_ to suggest that S*BASIC jobs are > self-contained within the job's area, even the VV area which (if I'm > reading it right) uses a 'private' Heap within the job's area, rather > than allocated from the Common Heap. It's all from the common heap, that at least I'm certain of. It's all in smsq_sbas_clear_asm > Also, the SB areas showed up as being out of (the documented) sequence, > with huge 'gaps' between one and the 'next', e.g. That's because they are allocated separately. That is also why you see newly introduced "top"-pointers in keys_sbasic, like sb_nmtbt, as the previous model where the base of the next area marks the top of the previous area is not valid anymore! Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
