Revise instruction encoding

jbush001 commented 6 years ago

The current encoding leaves gaps of unused encoding space. Unlike other architectures, the instruction format is explicitly encoded in the instruction, rather than being implied by the opcode.

This encoding scheme was originally done to simplify decoding. However, as I've needed to add instructions, I've started stuffing them into forms that don't make a lot of sense, which is making it much more complex than other encoding schemes.

A better approach might be to use a fixed width opcode field, with the rest of the format implied from the opcode, similar to many other RISC processors like RISC-V and Mips.

jbush001 commented 6 years ago

This allows solving issue #146 and #135 more cleanly, without having to bastardize the arithmetic formats.

jbush001 commented 6 years ago

[ ] In compiler Modify lib/Targets/Nyuzi/NyuziInstrFormats.td and NyuziInstrInfo.td to support new formats
[ ] Modify other code in backend that makes format assumptions (fixup code, etc)
[ ] Update tests/MC/Nyuzi for new format. Rewrite make_tests.py
[ ] Modify lld so fixups know new locations
[ ] Modify elf2bin to use new jump format
[ ] Modify LLDB for break instruction
[ ] Modify emulator to support new format
[ ] Modify instruction decode stage
[ ] Expand number of control registers (rename to CSR)
[ ] Decrease width of syscall index
[ ] Move thread enable and perf counter device regsiters into CSRs

jbush001 commented 6 years ago

Instruction Formats

Opcodes

Function Codes

Integer Arithmetic

Op	Code
or	0
and	1
xor	2
add_i	3
sub_i	4
mull_i	5
mulh_i	6
mulh_u	7
ashr	8
shr	9
shl	10

XXX Use _u and _i suffixes for shifts

Integer Comparison

Op	Code
cmpeq_i	0
cmpne_i	1
cmpgt_i	2
cmpge_i	3
cmplt_i	4
cmple_i	5
cmpgt_u	6
cmpge_u	7
cmplt_u	8
cmple_u	9

Floating Point Arithmetic

Op	Code
add_f	0
sub_f	1
mul_f	2

Floating Point Comparison

Op	Code
cmpeq_f	0
cmpne_f	1
cmpgt_f	2
cmpge_f	3
cmplt_f	4
cmple_f	5

Unary Arithmetic

Op	Code
ftoi	0
itof	1
reciprocal	2
sext8	3
sext16	4
ctz	5
clz	6

Memory Access

Op	Code
load/store u8	0
load s8	1
load/store u16	2
load s16	3
load/store 32	4
loadv/storev	5
load scat/gath	6
load/store sync	7

Cache Control

Op	Code
itlbinsert	0
dtlbinsert	1
tlbinval	2
tlbinvalall	3
dinvalidate	4
iinvalidate	5
dflush	6
membar	7

travisg commented 6 years ago

Oh that's a lovely set of tables. What tool are you using to generate them?

jbush001 commented 6 years ago

The bytefield package in Latex:

\usepackage{bytefield}

\begin{bytefield}[rightcurly=.,endianness=big,bitwidth=1.25em]{32}
  \bitheader{0-31} \\
  \begin{rightwordgroup} {R}
    & \bitbox{6}{opcode (6)}
    & \bitbox{5}{src1 (5)}
    & \bitbox{5}{dest (5)}
    & \bitbox{6}{func (6)}
    & \bitbox{5}{src2 (5)}
    & \bitbox{5}{mask (5)}
  \end{rightwordgroup}\\

  \begin{rightwordgroup} {I}
    \bitbox{6}{opcode (6)}
    & \bitbox{5}{src1 (5)}
    & \bitbox{5}{dest (5)}
    & \bitbox{4}{func (4)}
    & \bitbox{12}{imm (12)}
  \end{rightwordgroup}\\
\end{bytefield} \\

jbush001 commented 6 years ago

http://texdoc.net/texmf-dist/doc/latex/bytefield/bytefield.pdf

travisg commented 6 years ago

Very cool, thanks!

On Sun, Feb 18, 2018 at 3:16 PM, Jeff Bush notifications@github.com wrote:

http://texdoc.net/texmf-dist/doc/latex/bytefield/bytefield.pdf

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jbush001/NyuziProcessor/issues/145#issuecomment-366557310, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF9rIjTQsB41mR5QLRwvjOmY9lWttSzks5tWK82gaJpZM4SA85W .

jbush001 commented 5 years ago

An alternative would be to base this on RISC-V, using the RV32I with M+A+F extensions, then adding a non-standard extension for the vector operations.

jbush001 commented 5 years ago

The official RISC-V 'V' vector extensions seems to support most of the vectoroperations needed:

https://riscv.github.io/documents/riscv-v-spec/riscv-v-spec.pdf

jbush001 / NyuziProcessor