#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
+#define MAX_CHUNKS 256
+#define PAGES_PER_CHUNK 16
-/* 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. */
-
-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. */
+/* Sets: 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 */
+/* data types of the IR. 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 */
+/* of the cdat itself but rather in 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. */
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];
-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
by the grammar (CLOPEN), a cdat is pushed onto the cdat_stack, and we refer
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
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
and creating a relative pointer from the original object to the data that
was linked */
-/* Svlinks stand for short vlink, which is a link to a vdat
- TODO: diff btwn vlink*/
+/* Svlinks stand for short vlink, which is a link to a vdat. svlinks
+ differ from vlinks because they do not have a name */
struct svlink {
uint64_t ref_id;
};
-/* A vlink is what it sounds like, a link to a vdat
- TODO: model link? */
+/* A vlink is what it sounds like, a link to a vdat */
struct vlink {
uint64_t ref_id;
char anim_name[32];
struct svlink svlink;
};
+/* From: Some odat ()To: Another odat (ref_id)*/
struct link {
int type; //1 = olink, 2 = vlink, 3 = svlink
union link_t link_t;
- int cdat_idx;
+ struct cdat* classp;
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
TODO: Need more info about objects at runtime, to described
the reasoning behind odat structure at compile-time*/
-/* Each set has a quad_list or a list of quads. The quad_list
- is the ? */
-struct quad {
- int x, y, z;
- uint64_t ref_id; //rgba
-};
-
struct root {
int x, y, z;
};
struct odat {
char name[32];
- int vdat_id;
+ struct vdat* vdatp;
+ int vdat_id; //
int cdat_idx;
int hitbox;
+ uint64_t ref_id;
struct root root;
struct ref* refp; /* pointer to it's ref on ref_list */
- int num_quads;
- struct quad quad_list[MAX_QUADS];
+ void* quad_filep;
};
-/* 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) */
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 */
/* 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);
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
/* Inserts a quad into the CURR_ODAT */
void
-insert_quad(int, int, int, uint64_t);
+insert_quad(void*);
void
insert_model(void);
void
insert_frame_pointer(char, void*);
+void
+alloc_vdat(void);