PowerISA v3.1B specifies the precedence of operators in Book I section 1.3.4 page 8(34) Table 1. these don't match the parser's current state. Table 1: (edited slightly for clarity) +-----------------------------------+---------------+ | Operators | Associativity | +-----------------------------------+---------------+ | subscript, function evaluation | left to right | +-----------------------------------+---------------+ | pre-superscript (replication), | right to left | | post-superscript (exponentiation) | | +-----------------------------------+---------------+ | unary -, ¬ | right to left | +-----------------------------------+---------------+ | ×, ÷ | left to right | +-----------------------------------+---------------+ | +, - | left to right | +-----------------------------------+---------------+ | || | left to right | +-----------------------------------+---------------+ | =, ≠, <, ≤, >, ≥, <u, >u, ? | left to right | | (note: `?` is unordered | | | comparison, not a typo) | | +-----------------------------------+---------------+ | &, ⊕, ≡ | left to right | +-----------------------------------+---------------+ | | | left to right | +-----------------------------------+---------------+ | : (range) | none | +-----------------------------------+---------------+ | <-, <-iea | none | +-----------------------------------+---------------+
Today I ran into a bug directly caused by this, this needs to be higher priority. copying from bfp_ROUND_TO_BFP64 at PowerISA v3.1B page 603(629): the spec says: if ro=0 & rmode=0b00 then r <- bfp_ROUND_NEAR_EVEN(53, x) the spec says that condition is parsed as: (ro=0) & (rmode=0b00) however our parser incorrectly parses it as: (ro=(0 & rmode))=0b00 translating it to: eq(eq(ro, 0 & rmode), SelectableInt(value=0x0, bits=2))