| Summary: | setvl should not set SO | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Jacob Lifshay <programmerjake> |
| Component: | Specification | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | ghostmansd, libre-soc-isa |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| 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: | ||
| Bug Depends on: | |||
| Bug Blocks: | 587, 952, 1089 | ||
|
Description
Jacob Lifshay
2022-08-26 20:24:04 BST
it's more that "setvl." should not *read* XER.so... ahh but... in power_decoder2.py DecodeOE unconditionally reads the dec.OE flag which should *not* be happening, just as it should not be happening for e.g. mulh* rldic* etc. really there are enough exceptions in DecodeOE to justify adding a separate "OE" field - or, better, an RC.RC_NO_OE option. but that is... quite intrusive at the moment as it means dmitry has to update binutils, and the rest of the code which currently checks (and expects) RC.RC would need to check RC.RC_NO_OE. hmmm a separate CSV column would be better (In reply to Luke Kenneth Casson Leighton from comment #1) > it's more that "setvl." should not *read* XER.so... ahh but... > in power_decoder2.py DecodeOE unconditionally reads the dec.OE > flag which should *not* be happening, just as it should not > be happening for e.g. mulh* rldic* etc. imho the issue is that setvl. should not *write* SO or OV[32]. reading them is fine, since they can be assumed to be rarely modified. this is like how add. will read SO and write that to CR0, but it won't modify SO or OV. If we introduce OE into binutils, this will take the only bit left in svp64_record structure. We either need to find a clever way to compress the information we have there, or avoid introducing OE as Jacob suggests, or expand svp64_record structure, or introduce OE and never introduce anything else. Choose one. :-) |