[libre-riscv-dev] parser precedence, code review / checking needed

[Jacob Lifshay]

On Fri, Apr 3, 2020, 08:20 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> if anyone knows how to resolve operator precedence, my logic-dyslexia
> is kicking in and i am having difficulty working out which operators
> are supposed to be in which order, for bit-wise AND, OR, and
> PLUS/MINUS, MUL/DIV.  someone else did the PLUS/MINUS MUL/DIV, i'm
> attempting to add AND and OR and am getting it wrong
>

The way I always did it is by changing the grammar to have one non-terminal
symbol per precedence level. Example code from my LR(1) parser generator:
https://github.com/programmerjake/parser-generator/blob/master/test.parser#L108-L120

If I were writing the parser I would have used either a hand-written
recursive descent parser (what I used for the shader-compiler-ir text
parser) or a PEG parser, since PEGs don't have ambiguity since they are
defined in terms of the steps taken when parsing instead of being defined
in terms of what strings the rules can produce (LL(1) and LR(1) parsers).

>
> here's how python-ply is supposed to work:
> http://www.dabeaz.com/ply/ply.html#ply_nn27
>
> here's a patch showing the relevant files involved:
>
> https://git.libre-riscv.org/?p=soc.git;a=commitdiff;h=39c8314f9a14fb5351a9dcbc8bd37753bdcd0fee
>
> executing "python3 soc/decoder/power_pseudo.py" is a good test, with
> this being good example code:
> +cmpi = """
> +in_range <-  (x | y) & (a | b)
> +in_range <-  (x + y) - (a + b)
> +"""
>

since there are parenthesis, precedence between &, |, +, and - doesn't
actually matter here, so it's not a good example. Traditionally + and -
have the same precedence whereas & has higher precedence than | so a & b |
c parses as (a & b) | c.


> help appreciated.
>

Sure, I can figure it out for you if you like. Will be a few minutes.

Jacob