On Wed, May 20, 2015 at 10:45 PM, Keean Schupke <[email protected]> wrote:
> Visitors and maps. > > In my C++ compiler architecture I have used visitors and maps. The AST > just contains the basic term nodes, which then get annotated by type > inference. Each pass is implemented as a visitor over the AST tree that > maintains its state in a map private to the visitor object (which can be a > reference in the case of state shared between several passes) from > node-address to local state. > > You can do something similar by giving each node in the AST tree a node > ID. The AST structure is encoded directly in the tree, but different kinds > of metadata can be stored in a map from node-ID to datatype. This way you > can keep metadata local to the code that uses it. > It's an interesting thought, but perhaps my issue was unclear. It isn't so much the per-pass data that I'm concerned with. It's the data that *survives* the pass to be consulted by subsequent passes. E.g. the type inference/checking pass produces type information that we want to permanently associate with the AST nodes. A map could be used to do the association, but the overhead of that approach could be significant. We touch a *lot* of ASTs in every pass. If we need to do a map lookup for each one, that's an awful lot of instructions and memory references. In the end, this is pretty clearly a case where we want a single unboxed structure having both a variant and a non-variant part. Even if the non-variant part is merely a pointer to the common stuff, we still want to have at least that pointer. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
