![]() |
|||||||
![]() |
|
||||||
![]() |
|||||||
Symbol Table StructureAt Eastside Management Systems recently, Mike Taylor bemoaned the lack of any tools for enquiring about variable usage within an AREV program. In an effort to explore more about this subject we investigated the subject and the information presented below is the fruit of that research. Whenever an R/Basic program is compiled without the (C (Cutoff Symbol Table)) option, a record having the same name but preceded by an asterix is placed in the Source file. This is a record of the names of all the variables used/declared in the program. It is worth remembering that R/Basic does not actually see variables by name, rather it sees them by position - the first common variable, the second common variable etc. So this table is used by the debugger when displaying variable contents by name. The user types \WC_Is% and the debugger locates WC_Is% in the symbol table, establishes that the user means the 74th common variable and displays this. (This explains why a previous REVMEDIA tip about using SY to load a Window_Common% symbol table (to examine Window_Common when WINDOW falls over with VNAV) works). The Symbol table is Carriage Return/Line Feed delimited and has the following structure (Using the familiar < > nomenclature to indicate CrLfs not @Fms).
< 1 > Name of the record which was compiled to create this symbol
table. Note that this does not reflect the subroutine/function
name (which does not have to be the same as the record i.e. the
subroutine ProcessInvoice could have a Subroutine header on line
1 of "Subroutine Wombat", and the symbol table would still
contain ProcessInvoice).
Nor does it reflect the Catalog pointer name (which does not
have to be the same as the record i.e. the subroutine
ProcessInvoice could have a Catalog pointer called PI in VOC.
The Symbol table would still contain ProcessInvoice. Note
though, that when the system enters the debugger, the name of
the Catalog pointer is displayed, not the name of the original
source record.
< 2 > et seq One entry per variable. Each entry is in three parts,
comma separated where (again using < > to indicate commas)
< 1 > Is the variable name
< 2 > Is the variable type, with four values having
been identified thus far, these being
-1 local variable
1 common variable
2 labelled common variable
3 name of the labelled common block
< 3 > Is the sequential position of this variable
within the variable type, or in the case of
type 2 variables (labelled common) within that
labelled common block.
Thus a code segment as follows 0001 Subroutine InvoiceProcess(InvId, Options) 0002 Common Main1%, Main2% 0003 Common /Params/ Var1@, Var2@, Var3@ 0004 Common /Scratch/ S1@, S2@, S3@ 0005 Common Additional1%, Additional2% 0006 SaveId = InvId 0007 NewVar = "" 0008 Return would produce a symbol table as follows or where the Char(13) : Char(10) have not been shown, but where each line is shown separately
TEST Note, the record compiled was called TEST, so the
subroutine name was not used
INVID,-1,1 -1 - local variables. Note that as variables are
entered into the symbol table as they are encountered,
the first local variable entries for a subroutine will
be the variables that are passed to that subroutine.
OPTIONS,-1,2
MAIN1%,1,1 1 - common variables. Note that "like" variables are
not "grouped", so there will be more common variables
later in the table..
MAIN2%,1,2
PARAMS,3,1 The first labelled common name VAR1@,2,1
The first labelled common variable within the
preceding labelled common name
VAR2@,2,2
VAR3@,2,3
SCRATCH,3,2 The second labelled common name S1@,2,1
The first labelled common variable within the
preceding labelled common name
S2@,2,2
S3@,2,3
ADDITIONAL1%,1,3 The next set of common variables. Note the sequential
from the last set of common variables declared earlier
in the program.
ADDITIONAL2%,1,4
SAVEID,-1,3 And finally back to the local variables.
NEWVAR,-1,4
(Volume 4, Issue 9, Pages 12,13)
|
|||||||
![]() |
|||||||
| |||||||