On 13/05/2011 20:08, Marcel wrote:
How is it that some of these areas lie well outside of the traditional
> SBASIC job area?
>
> I have my own ideas, but hoped someone here (Marcel?) might be able to
> shed some light on how and where SBASIC is laid-out in SMSQ/E.
Frankly for me it's all pretty hazy what you're trying to do or asking
here.
Thanks for your reply, Marcel (and to Malcolm Lear's encouragement
off-list!)
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).
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.
As for what I'm trying to do that lead to all this peeking around, well...
I'm developing a block-based editor to allow SB program files to be
navigated and manipulated by blocks of code (notably DEFn's) as I hate
scrolling through by lines.
I decided early-on that I wanted the utility to work on a copy of the
tokenised program file (and associated Name List) and was looking for a
way to capture these portions of the loaded SB job being edited.
The output from QSAVE appeared uncomplete - in particular, the line
numbers in the Name List/Name Table header of the QSAVEd file are
missing (probably unneccessary as they are re-built when QLOADing),
hence I turned to the UNLOAD command mentioned above.
The sources of the SBASIC interpreter are out there and usually
well enough commented, though I concur that many things are still not
easy to understand;-)
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:
...
sb_offs equ $68 ; offset from JCB to SuperBASIC vars
sb_vars equ $1e8 ; base of SBASIC variables (rel JCB)
...
Generally everything in Basic is always relative to a Basic-area base
pointer. This is at a fixed offset from the JCB for SBasic jobs. I'm
not sure how job 0 is handled.
Sure.
The SBasic job working areas are generally allocated from the common
heap, so they are a) discontinuous and b) might be below A6 (therefore
negative offsets are possible).
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.
Also, the SB areas showed up as being out of (the documented) sequence,
with huge 'gaps' between one and the 'next', e.g.
Area Length St End
Input buf 10 256 266
Token buf 6 1280 1286
Program 23830 123544 147374
Name table 2856 89800 92656
Name list 2889 59848 62737
Variables 4080 -3110136 -3106056
Channels 200 -179720 -179520
Return 24 -790456 -790432
Lines 0 0 0
In practice, they do appear valid, just unexpected (to me, used as I am to the
old SuperBASIC days).
> b) Is there a SBASIC job-size stored in any_one_ place (as opposed
> to adding up the 'Length' bits above)
No. But why would one want to know this?
Well, if I am to capture the entire SB job, perhaps in a re-write of the
UNLOAD command, it seemed sensible to look for a total job size. I now
see that that approach is no longer valid as the SB areas are scattered
around memory (I'm sure for very good reason).
My research goes on...
Thanks for your input.
Martyn.
--
"There are 10 types of people in this world. Those who understand binary and those
who don't."
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
