Minimizing nested structure storage...

"Orlando Llanes" <>
30 Sep 2003 23:56:55 -0400

          From comp.compilers

Related articles
Minimizing nested structure storage... (Orlando Llanes) (2003-09-30)
Re: Minimizing nested structure storage... (Vijay Krishnan) (2003-10-04)
| List of all articles for this month |

From: "Orlando Llanes" <>
Newsgroups: comp.compilers
Date: 30 Sep 2003 23:56:55 -0400
Organization: Compilers Central
Keywords: storage, question
Posted-Date: 30 Sep 2003 23:56:54 EDT

        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...




        ...# 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...


        ...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!

Post a followup to this message

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