Bug 1082 - fix the pseudo-code parser's operator precedence to match PowerISA v3.1B
Summary: fix the pseudo-code parser's operator precedence to match PowerISA v3.1B
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- major
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 1035
  Show dependency tree / graph
 
Reported: 2023-05-12 03:58 BST by Jacob Lifshay
Modified: 2023-12-03 21:54 GMT (History)
2 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2023-05-12 03:58:40 BST 
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          |
+-----------------------------------+---------------+
Comment 1 Jacob Lifshay 2023-05-19 07:05:54 BST 
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))