riscv-opcodes
69 views
Skip to first unread message
Michael Clark
Mar 19, 2016, 8:05:03 PM3/19/16
to RISC-V ISA Specification Discussion, sw-...@groups.riscv.org
Hi All,
On the code side I have almost finished a polymorphic RISC-V decoder generator (intend to finish over Easter).
A new branch of riscv-opcodes is here:
https://github.com/michaeljclark/riscv-mc/blob/master/riscv-opcodes/
It looks very difference to the current riscv-opcodes however there are only minor semantic differences:
– added ISA extension membership
– shift instructions are duplicately defined due to RV64, RV128 encoding differences
– some reformatting and reordering of instructions to more closely match the specification
– modified section titles to match the ISA specification titles
– added decoder class which is a flattened namespace of distinct encodings
– parse-opcodes can ignore any of this additional meta data
– merger of opcodes, opcodes-pseudo, opcodes-rvc and opcodes-rvc-pseudo
– complete metadata for the compressed instruction set arguments
– removal or ignore opcode space placeholders which are ignored by parse-opcodes
– we are developing a tool to reflect on the opcode space so “ignore" may be redundant
– we may need to add back some @ symbols for the pseudo instructions to work with the chisel generator
It will be exhaustively tested before I consider making a pull request. i.e. boot linux and run the test suite on a decoder generated from these opcode files and check that the Chisel output is the same.
I have also added an additional <args> file that uses a notation similar to the specification so that the instruction metadata can be reflected on in any language (C++, C, JavaScript, Haskell, OCaml, Python, etc).
Please take a look and give me any feedback. I am almost about to finish working on C/C++ encode/decode generator. I can consider LaTeX generation. We could for instance annotate args with descriptions we want to appear in the documentation. We can make ASCII art, or even work on a RISC-V ISA Quick-Reference Guide. This would require us to extract concise one line descriptions of each instruction.
~mc
On the code side I have almost finished a polymorphic RISC-V decoder generator (intend to finish over Easter).
A new branch of riscv-opcodes is here:
https://github.com/michaeljclark/riscv-mc/blob/master/riscv-opcodes/
It looks very difference to the current riscv-opcodes however there are only minor semantic differences:
– added ISA extension membership
– shift instructions are duplicately defined due to RV64, RV128 encoding differences
– some reformatting and reordering of instructions to more closely match the specification
– modified section titles to match the ISA specification titles
– added decoder class which is a flattened namespace of distinct encodings
– parse-opcodes can ignore any of this additional meta data
– merger of opcodes, opcodes-pseudo, opcodes-rvc and opcodes-rvc-pseudo
– complete metadata for the compressed instruction set arguments
– removal or ignore opcode space placeholders which are ignored by parse-opcodes
– we are developing a tool to reflect on the opcode space so “ignore" may be redundant
– we may need to add back some @ symbols for the pseudo instructions to work with the chisel generator
It will be exhaustively tested before I consider making a pull request. i.e. boot linux and run the test suite on a decoder generated from these opcode files and check that the Chisel output is the same.
I have also added an additional <args> file that uses a notation similar to the specification so that the instruction metadata can be reflected on in any language (C++, C, JavaScript, Haskell, OCaml, Python, etc).
Please take a look and give me any feedback. I am almost about to finish working on C/C++ encode/decode generator. I can consider LaTeX generation. We could for instance annotate args with descriptions we want to appear in the documentation. We can make ASCII art, or even work on a RISC-V ISA Quick-Reference Guide. This would require us to extract concise one line descriptions of each instruction.
~mc
Andrew Waterman
Mar 20, 2016, 2:09:42 PM3/20/16
to Michael Clark, RISC-V ISA Specification Discussion, sw-...@groups.riscv.org
While we agree the current scheme isn't the greatest display of
software engineering, one point in its favor is that it really does
work :-)
As long as your PR doesn't remove functionality (including TeX, which
we specification writers rely upon), we're of course interested.
> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/08A51D68-B06D-40EA-887A-2C8DDE3F007B%40mac.com.
software engineering, one point in its favor is that it really does
work :-)
As long as your PR doesn't remove functionality (including TeX, which
we specification writers rely upon), we're of course interested.
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/08A51D68-B06D-40EA-887A-2C8DDE3F007B%40mac.com.
Reply all
Reply to author
Forward
0 new messages