-/* General: All information from the directory structure is stored in */
-/* five buffers that comprise the IR: cdat_buf, odat_buf, vdat_buf, ref_buf */
-/* and link_buf. Each buf corresponds to the data structure that it stores. */
-/* The storage techique for all bufs (except cdat) is the same. Each bufs member first */
-/* populates its struct and then allocates the space for the next member */
-/* and increments the buf index. This means that we have to allocate the */
-/* very first member of each buf at ir_init(), so that we don't segfault */
-/* as the first member attempts to access memory that its previous member */
-/* didn't allocate (because it doesnt exist). We access the buf members */
-/* through standard array indexing but conceal the tediousness of array */
-/* indexing with macros. E.g. without macros, acessing an elements name */
-/* member would look like (split up to not go over line char limit): */
-/* (*cdat_stackp)->set_list[(*cdat_stackp)->num_sets] */
-/* .ele_list[(*cdat_stackp)->set_list[(*cdat_stackp->num_sets)].num_ele].name */
-
-/* For cdats in cdat_buf, we allocate the memory for a cdat once a cdat
- is recognized in the grammar. Cdat_buf is different from the other bufs
- because cdats have a root cdat that all cdats are a subclass of. This root
- cdat can have a set_list like other cdats. */
-
-/* Elements: Ele stands for element and has two representations in the IR. */
-/* In the cdat_buf eles store their name, cdat_idx (their classes index in */
-/* the cdat_buf) and the ref_id (refer to ref ). In the odat_buf, eles store */
-/* their object data (odat). At output time, the ref_id is dereferenced to */
-/* determine the elements odat which is the data that the engine expects */
-/* from an element. */
-
-
-/* All bufs are of pointers to their respective structs. When a buf is full */
-/* (number of data structs pointers >= max number of data struct pointers), */
-/* we need to allocate a more pointers for that buf. Allocate these */
-/* pointers a page at a time (1024 = Page bytes (4096)/bytes per pointer(4)) */
-
-struct ele {
- char name[32];
- uint64_t ref_id;
- int cdat_idx;
-};
-
-/* Sets: The set is similar to the ele, but it contains a list of its */
-/* elements. The set is populated at parse time AFTER the elements are */
-/* populated, due to the nature of bottom up parsing. */
-
-struct set {
- char name[32];
- uint64_t ref_id;
- int cdat_idx;
- int num_ele;
- struct ele ele_list[MAX_ELES];
-};
-
-/* Cdats: A cdat is a class data structure. Cdats serve as the central */
-/* data types of the IR. At output, the cdat_buf is iterated through and */
-/* each is written to the output file. For each cdat, sets and element */
-/* ref_ids must be dereferenced to determine the odat information. Cdats */
-/* contain pointers to their subclasses so that the relationship between */
-/* classes can be determined, but the subclasses are not represented inside */
-/* of the cdat itself but rather in the subsequent cdats in cdat_buf. We */
-/* can determine the number of subclasses (the last index into cdat_buf */
-/* that represents a subclass of some arbitrary cdat) each cdat has by */
-/* incrementing num_classes during parse time. */
-/* TODO: Should classes point to their parent class? */
-
-struct cdat {
- char name[32];
- int idx;
- int num_classes;
- int num_sets;
- struct cdat* class_list[MAX_CLASSES];
- struct set set_list[MAX_SETS];
-};
-
-/* There are an unknown amount of cdats at compile time, so we maintain */
-/* a cdat_buf of cdat pointers that can be expanded as needed. */
-struct cdat* cdat_buf[PTRS_IN_PAGE];