parser-gen | Network packet parser generator | Parser library

This won't help you much because, as noted below, LL(1) parse tables generated for that grammar cannot be accurate.

However, for what it's worth, here's my reverse engineering of those tables. It's probable that you could get a deeper understanding of this procedure by reading the text book referenced by the tool. (Note: link is not an endorsement, neither of the book nor of the vendor. I just copied it from the tool.)

The terminal symbols appear in order in the top row of the parse table (the one which the instructions say should be removed for use). So terminal symbol 1 is ',', symbol 2 is '+', and so on up to symbol 46, which is the $ conventionally used as an end-of-input marker. (That's different from '$', which would be a literal dollar sign.)

Non-terminal symbols don't appear explicitly (so you can't recover their names from the tables) but they are also numbered in order. There are 54 of them, and each row of the parse table (after the first two) corresponds to a non-terminal symbol.

There are 110 productions, which are listed (with their corresponding index) in the Predict set section of the output from that tool. Each production corresponds to one entry in the "push map", which (for reasons unknown to me) uses the string conversion of the production number as a key.

The corresponding value in the push map is a list of indices: negative indices refer to terminals and positive indices refer to non-terminals. The index 0 is not used, which is why row 0 of the parse map is unused. From these indices, it is possible to reconstruct the right-hand side of the production, but they are actually used to indicate what to push onto the parse stack at each step in the parse.

The stack contains the list current predictions, with the top element of the stack being the immediate prediction at this point in the parse.

So the algorithm is as follows:

1. Initialise the parser stack to [1, -46], which indicates that the current prediction consists of the right-hand side of the production -> followed by the end-of-input marker $.

2. Repeat the following until terminated by an error or by acceptance:

   1. If the top of the stack is negative:
      • If the lookahead token has the corresponding token number (that is, the absolute value of the stack top), then pop the stack and accept the lookahead token. If that token is the end-of-input indicator, then the parse is finished and the input was valid. Otherwise, the new lookahead token is the next input token.
      • If the lookahead token does not correspond with the top of the stack, then the input is incorrect. Report an error and terminate the parse.
   2. If the top of the stack is positive:
      • Retrieve the value rhs from parseTable[stack.top()][lookahead]. If rhs has a value greater than the number of productions (in this case, the values 111 or 112) then the input is incorrect. Report an error and terminate the parse. (The value will tell you whether it was a scan error or a pop error, but that might not make much difference to you. It could be used to improve error reporting.)
      • Pop the parse stack, and push the elements from pushMap[rhs] onto the stack, starting at the end. (For example, if rhs were 4, you would use the list from pushMap["4"], which is [10, -1]. So you would push first -1 and then 10 onto the parser stack.)
      • For the push-map generated by the hacking-off tool, it appears that there will be no entry in the pushMap for ε right-hand sides. So if pushMap[rhs] doesn't exist, you just pop the parse stack; there is nothing to push.

That algorithm does not include any procedure for producing a syntax tree for successful parses. But if you want to do anything more than just decide whether the input is a valid program or not, then you will definitely want to produce some kind of syntax tree.

I don't know how much credibility you should give the tool you are using.

Your grammar is not LL(1), but the tool does not provide any indication of that fact.

A simple example is