fix(gen): support subtype-based encodings in C header generator #904
Conversation
blazethunderstorm
requested review from
dhower-qc and
ThinkOpenly
as code owners
blazethunderstorm
changed the title
|
@ThinkOpenly pls see now |
|
I don't think these changes have any impact. Are you seeing some problems being resolved? I would expect that instead of finding the needed "match" string directly, you'd need to compute it by going into the "format" attribute and its children "opcodes" and "variables". Note that these changes would likely appear in Part of your mission is to make those error messages go away. The current code just extracts the value of the "match" attribute, but you'll need to compute it. |
|
@ThinkOpenly would do that |
|
Thanks for the contribution! Like @ThinkOpenly said, you'll need to build up what used to be explicit in 'match'. Basically, start with an instruction-length string of '-'s and then replace any position that is occupied by an opcode value. So if you have: # andn.yaml
format:
funct7:
display_name: ANDN
location: 31-25
value: 0b0100000
funct3:
display_name: ANDN
location: 14-12
value: 0b111
opcode:
display_name: OP
location: 6-0
value: 0b0110011You want to wind up with the string:
|
|
@dhower-qc thanks for help would make the changes as req |
|
@ThinkOpenly @dhower-qc pls review |
| if value is None or location is None: | ||
| continue | ||
|
|
||
| if isinstance(location, str) and "-" in location: |
There was a problem hiding this comment.
You need to handle when location does not have -. They all do today, but this is not guaranteed. In this case, the field is a single bit.
| except Exception as e: | ||
| logging.error(f"Failed to construct match string for {name} in {path}: {e}") | ||
| encoding_filtered += 1 | ||
| continue |
There was a problem hiding this comment.
Do we need this? This would have the effect of logged, but otherwise ignored errors. We may actually want a crash here.
| encoding_filtered += 1 | ||
| continue | ||
|
|
||
| continue |
There was a problem hiding this comment.
does this have any effect?
| @@ -255,14 +283,30 @@ def load_instructions( | |||
| encoding_filtered += 1 | |||
| continue | |||
|
|
|||
| match_str = encoding_to_use.get("match") | |||
| match_str = encoding_to_use.get("match") if encoding_to_use else None | |||
| mask_str = encoding_to_use.get("mask") if encoding_to_use else None | |||
There was a problem hiding this comment.
Do we need to do any work with "mask" here? I thought it was calculated elsewhere based on the "match" string.
|
@ThinkOpenly would think about this and inform you and make changes |
Fixes #893
Updated the generator.py to correctly detect instruction encodings when using the new type/subtype schema. Previously, it looked only for the old encoding field, so some instructions were skipped. Now it checks subtype fields and extracts encoding info from there.