Bug 757 - bitmanip instruction encodings -- adjust to match existing X/XO-forms?
Summary: bitmanip instruction encodings -- adjust to match existing X/XO-forms?
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's second ASIC
Classification: Unclassified
Component: source code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 741 755
  Show dependency tree / graph
 
Reported: 2021-12-17 03:56 GMT by Jacob Lifshay
Modified: 2022-01-06 03:09 GMT (History)
3 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 2021-12-17 03:56:23 GMT 
Currently, the encoding for bitmanip instructions such as grevi have the sh fields split across several different ranges, bits 16 to 20 and bit 23. Also the XO field is split across 21 to 22 and 24 to 30. This has little in common with any existing instructions.

0.5  6.10  11.15  16.20  21.22  23  24....30  31  name
NN   RA    RB     sh     01     SH  1010 110  Rc  grevi

I propose that we instead use an encoding like the XO and X forms:
# 1.6.16 XO-FORM (trimmed)
   |0     |6   |11   |16     |21 |22    |31  |
   | PO   |  RT|   RA|   RB  |OE |   XO |Rc  |

# 1.6.7 X-FORM (trimmed)
   |0     |6   |11  |16  |21   |31  |
   | PO   | RT | RA | RB |  XO |Rc  |


Proposed encodings:
   |0     |6   |11   |16     |21 |22    |31  |
   | PO   |  RT|   RA|   SH      |   XO |Rc  | grevi (kinda XO-form)
   | PO   |  RT|   RA|   RB  |       XO |Rc  | grev (X-form)

To get the new encoding, take the old encoding and remove bit 23, inserting it before bit 21, so it becomes the new bit 21 and bit 21:22 are shifted over 1 to 22:23.
Comment 1 Jacob Lifshay 2022-01-06 03:00:29 GMT 
Well, since no one apparently has any comments, I'm going to just make the changes I proposed.