instr_dict should contain instruction format #149
Comments
|
The basic formats are an illustrative abstraction. There are so many minor formats (see the C and Zcb extensions) that doing this fully and correctly would require naming several currently unnamed formats and labeling all of the instructions manually. It’s not an insurmountable task, and it does have some value, but it isn’t quick or automatable. |
|
@aswaterman Thanks for your insight. It makes sense that my proposed solution is not robust because there are lots of unnamed formats. With this in mind, do you think the better approach is to support #136? I believe that these attempt to solve the same issue. I'm willing to contribute in whatever way is needed. I think this is important for the RISCV spec. Let me know if this is something you'd be interested in. |
|
Something along those lines would allow programmatically indicating which instruction bits map to which immediate bits without labeling every instruction format, which might be more appropriate. I think we'd need a volunteer to propose a concrete format and get feedback on it before proceeding. @neelgala and I should be in the loop on such an effort. |
|
Sure thing. If you're open to it, I can take some time to come up with a complete schema and we can begin iteration from there. |
|
Go for it. Thanks for volunteering! |
|
So one option is to define a json schema. The benefit of this is that it can be trivially parsed and validated. Users would only have to worry about using the data. The downside to this approach is its verbosity. Data example: {
"JAL": {
"rd": [
{ "dst": [0, 5], "src": [7, 11]}
],
"imm20": [
{ "dst": [ 0], "tie": 0 },
{ "dst": [ 1, 10], "src": [21, 30] },
{ "dst": [11], "src": [20] },
{ "dst": [12, 19], "src": [12, 19] },
{ "dst": [20, 31], "src": [31] }
]
}, ...
}Schema: {
"$schema": "https://json-schema.org/draft-07/schema",
"$id": "risc-v://variable-encodings.schema.json",
"type": "object",
"additionalProperties": {
"$ref": "#/$defs/VariableEncoding"
},
"$defs": {
"VariableEncoding": {
"type": "object",
"additionalProperties": {
"$ref": "#/$defs/Encoding"
}
},
"Encoding": {
"type": "array",
"items": {
"oneOf": [
{
"$ref": "#/$defs/ConstMapping"
},
{
"$ref": "#/$defs/RangeMapping"
}
]
}
},
"RangeMapping": {
"type": "object",
"properties": {
"src": {
"$ref": "#/$defs/InclusiveRange"
},
"dst": {
"$ref": "#/$defs/InclusiveRange"
}
},
"required": [
"src",
"dst"
]
},
"ConstMapping": {
"type": "object",
"properties": {
"tie": {
"type": "integer",
"inclusiveMin": 0,
"inclusiveMax": 1
},
"dst": {
"$ref": "#/$defs/InclusiveRange"
}
},
"required": [
"tie",
"dst"
]
},
"InclusiveRange": {
"type": "array",
"items": {
"type": "integer"
},
"minItems": 1,
"maxItems": 2
}
}
} |
|
Hello, I'd like this to happend too. How about add another file (eg: Similiar to
In |
|
I'm still fine to take this on if we can settle on a format. I know my json schema was probably a little too verbose! |
Yes, let's see how it will work. @neelgala @aswaterman a friendly ping. |
This repo has been very useful for gathering information about the ISA in a programmatic way. I think one of the shortcomings is that it doesn't contain any information about the instruction format (ex:
I, J, U ...). This could be used to programmatically verify that implementations are handling the instructions in a correct manner.Currently I do this manually by cross-referencing the spec itself. Is there a better way to do this?
The text was updated successfully, but these errors were encountered: