Minimizing nested structure storage...

        I was thinking of how to reduce the amount of memory needed to
store nested structure declarations, while at the same time avoiding
the use of tree structures.


        I'm planning on representing heirarchy in a flat structure. The
symbol table will be a hash table. Each hash table entry will be a
pointer to a sorted dynamic array that handles collisions. A modified
binary search will be used to insert an entry if a collision occurs.




        The following type declarations...


typedef struct level1_s
{
        int a, b;
} level1;


typedef struct level2_s
{
        level1 c, d;
} level2;


typedef struct level3_s
{
        level2 e, f;
} level3;


        ...would be stored as...


level1#a
level1#b


level2>
level2#d


level3#e
level3#f


        ...# is an arbitrarily chosen character, which would otherwise be
invalid for an identifier, so that nested structure names do not clash with
any other names (ie: "level1_a").




        The following variables...


        level2 foo;
        level3 bar;


        ...would parse as...


        foo.c.b = 1234;
        1) foo -> level2
        2) c -> level2>
        3) level2> -> level1
        4) b -> level1#b
        5) Emit move [address(foo) + offset], 1234


        bar.e.d.a = 1234;
        1) bar -> level3
        2) e -> level3#e
        3) level3#e -> level2
        4) d -> level2#d
        5) level2#d -> level1
        6) a -> level1#a
        7) Emit move [address(foo) + offset], 1234


        Step 1 looks for the type name and variable address
        Steps 2 through n-1 combines the previous type name with the next
                field name and keeps a running total of the field offset
        Step n uses the address and resulting offset (ie: emitting code)




        If someone tries to trick the compiler with the following...


        foo.a.f


        ...the compiler would flag an error upon reaching "a" since "level3#a"
has not been declared.




        Are there any flaws with this design?




See ya!
Orlando

Return to the comp.compilers page.
Search the comp.compilers archives again.