api with struct definitions in header file
[henge/webcc.git] / src / apc / ir.h
index d8a7ec3..cc0508f 100644 (file)
@@ -14,7 +14,6 @@
 
 
 #include <stdint.h>
-//#include <apc/mem.h>TODO:
 
 #define BUF_SIZE 256
 #define MAX_SETS 256
 #define MAX_CLASS_DEPTH 256
 #define MAX_CLASSES 256
 #define MAX_FRAMES 256
-/*  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))   */
-/*  TODO: Account for different page sizes in different system                  */
 #define PTRS_IN_PAGE 1024
 
 /*  General: All information from the directory structure is stored in        */
    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     */
+extern struct cdat** cdat_stackp;
 /*  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;
@@ -103,9 +101,6 @@ struct cdat {
 
 /* 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];
-int num_cdats = 0;
-int curr_max_cdats = PTRS_IN_PAGE;
 
 /* The cdat_stack is a stack pointers to cdat pointers, the top of which is
    the cdat that is currently being parsed. Whenever a new cdat is recognized
@@ -114,8 +109,6 @@ int curr_max_cdats = PTRS_IN_PAGE;
    access to the current cdat so that the elements and sets can populate themselves
    in the cdat accordingly. */
 
-struct cdat* cdat_stack[PTRS_IN_PAGE];
-struct cdat** cdat_stackp;
 
 /* Refs: Each set/ele has a reference to its object data (odat) through a ref_id.
    Ref_ids are unsigned 64 byte integers that map to the hex values RGBA. During
@@ -135,17 +128,11 @@ struct ref {
   uint64_t ref_id; //0xFFFFFF->digit
 };
 
+
 /* Like the cdat_buf, ref_buf stores pointers to refs and can
    increase in size */
-struct ref* ref_buf[PTRS_IN_PAGE];
-int num_refs = 0;
-int curr_max_refs = PTRS_IN_PAGE;
-uint64_t ss_ref_id = 0x00FFFFFF; /* system space for ref_ids */
-
 
 /* posts for ref_buf */
-struct ref posts[MAX_POSTS];
-int num_posts;
 
 /* Links: At parse time, a set/ele can include a link in their
    grammar representation instead of the actual data and this signifies
@@ -191,14 +178,12 @@ struct link {
   int set_idx;
   int ele_idx;
 };
+
 /* link_buf contains all the links that
    we encountered during parse time that need
    to be resolved to an offset at output time.
    This does not include quad refs, because
    those are already known to need to be resolved */
-struct link* link_buf[PTRS_IN_PAGE];
-int num_links = 0;
-int curr_max_links = PTRS_IN_PAGE;
 
 
 /* Odats: Odats consist of the object data necessary for
@@ -230,10 +215,8 @@ struct odat {
   struct quad quad_list[MAX_QUADS];
 };
 
-/* Populated and allocated same way as other bufs */
-struct odat* odat_buf[PTRS_IN_PAGE];
-int curr_max_odats = PTRS_IN_PAGE;
-int num_odats = 0;
+struct odat* curr_set_odatp; //when a set has elements, insert_set() can no longer
+                            //refer to its odat via curr_odat, so save the set odat. 
 
 /* A framesheet is a grouping of animation frames in
    a single direction (N,W,S,E) */
@@ -263,22 +246,6 @@ struct vdat {
   struct model model_list[MAX_MODELS];
 };
 
-
-struct vdat* vdat_buf[PTRS_IN_PAGE];
-int curr_max_vdats = PTRS_IN_PAGE;
-int num_vdats = 0;
-
-/* The initalization function of the IR. Mallocs the
-   first c/v/odat and the first links and refs and
-   inits the cdat_stack */
-void
-ir_init(void);
-
-/* mallocs memory for a new cdat. If the cdat_buf
-   is full, mallocs another 1024 cdat pointers. */
-void
-malloc_cdat(void);
-
 /* Called after the cdat open operator has been recognized in grammar. Allocates
    the space for a cdat on the cdat_buf, pushes that pointer onto
    the cdat_stack */
@@ -292,31 +259,7 @@ pop_cdat(void);
 
 /* Called after an odat has been populated. Allocates memory for
    the next odat. */
-void
-inc_odat(void);
 
-/* Called after an vdat has been populated. Allocates memory for
-   the next vdat. */
-void
-inc_vdat(void);
-
-void
-inc_link(void);
-
-void
-inc_ref(void);
-
-/* Called in the reduction of a set. While both odats (eles and sets)
-   have identical label terminals, we are unable to give a single grammatical rule
-   for both due to how we allocate odats in the odat buf. Due to the
-   nature of bottom up parsing, all the elements will be inserted into the
-   odat_buf first, and then the set that contains these element is inserted. Since
-   the sets label comes before the element list in the grammar, we would be giving an element
-   a set label in its respective odat, which would then be replaced by the
-   elements label. Instead, we store the label in the sets representation inside
-   CURR_CDAT and after we are done parsing the element_list and know that the CURR_ODAT
-   is the set, we populate the sets label members in CURR_ODAT with the values we stored
-   previously in CURR_CDAT. */
 void
 insert_set_label(char*, uint64_t);
 
@@ -345,29 +288,30 @@ insert_set(void);
    and odats. Eles have the added notion of a parent set, and so must be inserted
    into said parent set, but this is the only place they truly differ from sets. */
 
+void
+insert_set_vdatid(void);
+
 void
 insert_ele_label(char*, uint64_t);
 
+/* Insert an ele olink into the CURR_ODAT */
 void
 insert_ele_olink(uint64_t);
 
+/* Insert a ele vlink  into CURR_ODAT*/
 void
 insert_ele_vlink(uint64_t, char*);
 
+/* Inserts an ele short vlink into CURR_ODAT*/
 void
 insert_ele_svlink(uint64_t);
 
+/* inserts ele into CURR_CLASS and CURR_ODAT */
 void
 insert_ele(void);
 
-/* Created as a seperate function, instead of setting the ODATS vdat_id and
-   calling inc_vdat() inside of insert_set(), to account for the set reduction
-   where a vdat is not created (o/v/svlinks). Because insert_set/ele is always
-   called before insert_vdat, and thus increments the CURR_ODAT to be the next
-   ODAT to be populated, insert_vdat() targets the last ODAT that was populated,
-   via PREV_ODAT. */
 void
-insert_vdat(void);
+insert_ele_vdatid(void);
 
 /* Inserts the hitbox into the CURR_ODAT */
 void
@@ -390,3 +334,5 @@ insert_framesheet(char, char*, uint64_t, int, int, int);
 void
 insert_frame_pointer(char, void*);
 
+void
+alloc_vdat(void);