Scope Analysis : structs/records

[cman]

Have a question concerning structure/record handling and the compilers definition table. When a defining occurrence of a structure is encountered in a given scope my design adds a definition for the new name to the table along with a pointer to the node in the associated parse tree with the structures signature. By defining occurrence I mean something like:

Code Select Expand



struct myStruct
{
     byte myChar;
     word myInteger;
};




When a applied occurrence definition of the struct is encountered a new entry is then made in the definition table in the current scope. By applied occurrence , I mean something like:

Code Select Expand



myStruct myNewStructure;




A definition of the above name is entered in the table  and a  number is then associated with the structures name that indicates a new block  ( index to a new scope in the definition table - an array starting with 0 for global scope and so on ) and new definitions for the structure field variables are set up in that block ( new entries in the definition table are set up in the new "scope" - a new dynamic node is entered in the array at the number associated with the original  name for each field member ). If a field member is accessed in the source , like :

Code Select Expand



myNewStructure.myChar = 'a';



the current scope is searched for the name "myNewStructure" and when found the definition key for the structures field variables is found by jumping to the scope indicated in the definition of "myNewStructure" where the field variables are defined . Is this a feasible/efficient solution to the name analysis of structured data types? What is the common stategy? Thanks for any input! :bg

[tenkey]

Does that mean that

myStruct s1, s2;

will create two entries containing myChar definitions ?

If so, that seems wasteful. A pointer (or index) to the structure/record definition would allow sharing - field names represent fixed offsets, and the names don't change.

[cman]

Does that mean that

myStruct s1, s2;

will create two entries containing myChar definitions ?

If so, that seems wasteful. A pointer (or index) to the structure/record definition would allow sharing - field names represent fixed offsets, and the names don't change.

Yes , each would have its own scope and unique definition key associated with its name ( s1.myChar or s2.myChar ) and the original definition of myStruct will be stored at the index of the block where it was originally defined by means of an entry with the name myStruct and a pointer to the signature of myStruct in the parse tree. With this design ( which I'm considering changing to that of a tree of definitions per scope with the outside scope at the root of the tree and subscopes as the root scopes children )  a new entry is made in the block table for each subscope within a scope. So for example , we have this situation:

Code Select Expand



byte myFunction ( word myParameter )
{

    ........

   struct myStruct
   {
       byte myChar;
       word myInteger;
   };


   myStruct s1;

   ...
   return 'a';
}



The block table looks like:

Code Select Expand



  .......................
  [ myFunctionIndex ]  --> {  name = myStruct;
                                        structSignature = parseTreeNode;
                                        definitionKey = thisDefinitionKey;
                                        entryType = recordDefinition;
                                        parentScope = global;
                                        ......
                                        definitionNode = nextDefinitionInList;
                                      }

[ myStructIndex ]    -->   { name = s1
                                        definitionKey = thisDefinitionKey;
                                        entryType = structInstance;
                                        definitionNode = structFieldMembers;
                                        parentScope = myFunction;
                                        ....
..........................



but I'm thinking of changing this to a scope tree for each new scope that will be associated with the appropriate node in the parse tree , like:

Code Select Expand



                             myFunctionScope
                                        |
                                    myStruct
                                    /       \
                                   /         \
                                  /           \
                                 s1            s2


and a pointer to this tree would be stored at the node for the definition of myFunction......

[tenkey]

This is the way I would organize the definition of two structure variables:

Code Select Expand



                                    myFunctionScope
                                    /       \      \
                                   /         \      \
                                  /           \      \
                                 s1            s2     myStruct
                                  \           /
                                   \         /
                                    \       /
                                     myStruct

I like to think of structure definitions as type definitions.

The links from s1 and s2 to myStruct are type links, rather than (block) definition links. The definition for myStruct fields will contain an offset for compilation, or slot numbers for interpretation.

What you're proposing sounds like an in-lined or macro-ized version of the above structure, where my links to a structure definition are replaced by separate sets of field definition entries. "Naive" code generation can proceed without this "expansion". At the moment, I can't think of any optimizations that require this expansion.

[cman]

OK , thanks for the information! If I come about any more design problems I'll post. Thanks again! :bg