-
Notifications
You must be signed in to change notification settings - Fork 153
feat: optimize C extensions #1814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| { | ||
| "$schema": "http://json-schema.org/draft-07/schema#", | ||
| "$id": "v0.2", | ||
| "$id": "v0.3", | ||
| "$defs": { | ||
| "fully_resolved_opcodes": { | ||
| "type": "object", | ||
|
|
@@ -267,6 +267,15 @@ | |
| "default": 0, | ||
| "description": "Amount the field should be left shifted before use (e.g., for opcode[5:3], left_shift is 3)" | ||
| }, | ||
| "add": { | ||
| "type": "integer", | ||
| "default": 0, | ||
| "description": "Amount the field should be added before use, e.g., source register is ranged between 8 to 15, add is 8" | ||
| }, | ||
| "implicit": { | ||
| "type": "integer", | ||
| "description": "Implicitly use an operand with the value" | ||
| }, | ||
|
Comment on lines
+275
to
+278
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we do need something like this. You've applied it to opcode fields, but the variable fields are by definition, variable, and "implicit" by definition is not really variable, so it's not a great fit. The implicit content seems to be more closely associated with operands (which is the approach in #1527): the input to the instruction. It is a bit subjective. Either way, I think it needs to be generalized to at least cover:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm fine with moving it to the fields other than variable. To integrate with new operand field, I have some ideas:
$schema: "operand_schema.json#"
kind: operand
name: sp-implicit
data:
$inherits: operand/xs.yaml#/data
possible_values: [2]
implicit: true
$schema: "operand_schema.json#"
kind: operand
name: xs-pair
data:
type: reg_pair
name: reg_pair_xs
possible_values:
- $inherits: operand/xs.yaml#/data
name: ["x0", "zero"]
values: [0, 1]
- $inherits: operand/xs.yaml#/data
name: ["x2", "sp"]
values: [2, 3]
- $inherits: operand/xs.yaml#/data
name: ["x4", "tp"]
values: [4, 5]
...
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good ideas. Feel free to post them in #1527. (Or, I'll copy them there if you wish.)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks! I'll copy them to the PR. |
||
| "alias": { | ||
| "type": "string", | ||
| "description": "Alias of the field. Used when a field can represent multiple things, e.g., when a source register is also the destination register" | ||
|
|
@@ -286,7 +295,14 @@ | |
| "description": "Specific value(s) that are not permitted for this field." | ||
| } | ||
| }, | ||
| "required": ["name", "location"], | ||
| "oneOf": [ | ||
| { | ||
| "required": ["name", "location"] | ||
| }, | ||
| { | ||
| "required": ["name", "implicit"] | ||
| } | ||
| ], | ||
| "additionalProperties": false | ||
| } | ||
| ] | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,7 @@ encoding: | |
| - name: xd | ||
| location: 11-7 | ||
| not: 0 | ||
| alias: xs1 | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn't even know UDB had this feature. Are you adding this just to match the ISA manual? Do you have a use-case for it? Just curious. It seems pretty harmless, so no objections.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, just to match ISA manual. But I think it also beneficial for someone who wants to use this database for compiler scheduling or RTL decoder generation. For these purposes, you must know these operands are used for both source and destination. I think with new operand system. We could just create a new xsdc operand for this purpose. $schema: "operand_schema.json#"
kind: operand
name: xsdc
data:
$inherits: operand/xdc.yaml#/data
source: true
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree. I didn't yet model a source/destination register, but I think the capability is already there (as in your example). |
||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,9 +22,11 @@ encoding: | |
| - name: imm | ||
| location: 12|6-2 | ||
| not: 0 | ||
| sign_extend: true | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure. I'll file another PR for this in Edit: A few minutes actually 😅 |
||
| - name: xd | ||
| location: 11-7 | ||
| not: 0 | ||
| alias: xs1 | ||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,44 @@ encoding: | |
| location: 12|4-3|5|2|6 | ||
| left_shift: 4 | ||
| not: 0 | ||
| sign_extend: true | ||
| - name: xd | ||
| location: 11-7 | ||
|
Comment on lines
+27
to
+28
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm guessing this fails to validate properly, as this new "variable" is hardcoded to 2 ("00010") in the "match" string just above. Try running An open question, perhaps: where is the syntax defined for
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I forget to change mask "00010" to "-----". I think two approaches are valid:
I don't think
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh. Thanks for digging up that (very sad) reference. 😕 Not a choice I would've made.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a strange case, indeed. Making the field a "variable with only one possible value" seems a little odd. Making "sp" an implicit operand when it is explicitly there also seems odd. This instruction is odd. I could be swayed either way, but prefer the "variable with one possible value", if you want to update the mask.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer the "variable with one possible value", too. But I want to use new operand system to do it instead of handcoding 0-31 exclude 2.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should do both the field and the operand. We do want to properly constrain the field so that simple decode won't match (if the purpose of the decode was to execute rather than disassemble, for example). |
||
| not: | ||
| [ | ||
| 0, | ||
| 1, | ||
| 3, | ||
| 4, | ||
| 5, | ||
| 6, | ||
| 7, | ||
| 8, | ||
| 9, | ||
| 10, | ||
| 11, | ||
| 12, | ||
| 13, | ||
| 14, | ||
| 15, | ||
| 16, | ||
| 17, | ||
| 18, | ||
| 19, | ||
| 20, | ||
| 21, | ||
| 22, | ||
| 23, | ||
| 24, | ||
| 25, | ||
| 26, | ||
| 27, | ||
| 28, | ||
| 29, | ||
| 30, | ||
| 31, | ||
| ] | ||
| alias: xs1 | ||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,9 @@ encoding: | |
| sign_extend: true | ||
| - name: xs1 | ||
| location: 9-7 | ||
| add: 8 | ||
| - name: xs2 | ||
| implicit: 0 | ||
|
Comment on lines
+27
to
+28
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There are a number of changes like this.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I just want to align the theoretical expansion to the base instruction. But it's totally fine not to do this.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's not. I think it would be confusing. There is already enough information to get the right values for all of the operands in the base instruction. |
||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,6 +20,8 @@ encoding: | |
| - name: xs1 | ||
| location: 11-7 | ||
| not: 0 | ||
| - name: xd | ||
| implicit: 1 | ||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,6 +20,8 @@ encoding: | |
| - name: xs1 | ||
| location: 11-7 | ||
| not: 0 | ||
| - name: xd | ||
| implicit: 0 | ||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -26,6 +26,8 @@ encoding: | |
| - name: xd | ||
| location: 11-7 | ||
| not: 0 | ||
| - name: xs1 | ||
| implicit: 2 | ||
| access: | ||
| s: always | ||
| u: always | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,7 @@ name: c.mv | |
| long_name: Move Register | ||
| description: | | ||
| C.MV (move register) performs copy of the data in register xs2 to register xd | ||
| C.MV expands to addi xd, x0, xs2. | ||
| C.MV expands to add xd, x0, xs2. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another bug fix for a separate PR. |
||
| definedBy: | ||
| extension: | ||
| name: Zca | ||
|
|
@@ -20,6 +20,8 @@ encoding: | |
| - name: xd | ||
| location: 11-7 | ||
| not: 0 | ||
| - name: xs1 | ||
| implicit: 0 | ||
| - name: xs2 | ||
| location: 6-2 | ||
| not: 0 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, while this is useful in isolation, it presents some challenges by only solving one arithmetic issue, and leaves others (like additional operators and "precedence") unresolved. In #1527, I'm trying to lump all of the operand<->field transformations into new, general
encode()anddecode()methods. These are IDL, which allows most any transformation, but also complicates their use. Would these methods accommodate your use-case well enough?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True.
encode()anddecode()should be enough for this. With these 2 functions, I thinkleft_shift()could be merged into them, too.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True.