-
David Hancock authored
In parserSample02, I illustrate an issue that will be difficult to resolve: each path through the parse tree could result in a different mapping between HyPer4's consolidated extracted.data field and the source .p4's header fields. Thus has several implications: 1) tset_control_state_nextbits is insufficient as it incorrectly assumes that of all paths leading to a given parse state, those paths that incur the same bit extraction requirement prior to entering the parse state may all be represented by this value (the number of bits that have been extracted). This is incorrect because for some paths the number may represent explicit 'extract' statements while for other paths the number may include (or completely consist of) support for handling 'current' expressions in preceding parse states' return statements. 2) We will have to store each possible extracted.data -> source.p4 field mapping, indexed by the final path taken through the parse tree from start to ingress, and for each possible path incurring a different mapping, we will have to supply different match table entries, meaning the path ID will have to be added to the match fields, resulting in a multiplication of the memory required for emulating source.p4 table entries. 3) Back in the parse tree compilation, we will have to deal with implications for issuing the correct tset_inspect_XX_XX entries, where different paths may require different entries and even different tset_inspect_XX_XX tables (if the different mappings mean the select expression, in the parse state's return statement, has to look at different sets of bytes crossing tset_inspect_XX_XX boundaries).
d9486a08