Support for C extension (Compressed Instructions)

[lcgamboa]

First of all, thank you for your work at Ripes which is an excellent and didactic simulator.
My question is what is the possibility and difficulty of adding support for C extension (Compressed Instructions) in Ripes?

[mortbopet]

There's two major parts to this; support in the assembler and support in a/the instruction model(s). The assembler, as it stands now, should be generalized to both variable register and instruction length. However, I've only really tested/worked with variable register length (for supporting RV32 and RV64).
Secondly, support must be added in the processor models. This is mostly up to the implementer to figure out how to do in the smartest way, but i think expanding the compressed instructions during instruction decode is the best way to go. That + modifications to PC incrementation, but it should be nothing severe.

I have a lot on my plate at the moment, so it is not something that would be on the top of my priority list. I'd be open to look into the assembler support if someone volunteers for taking a look at the processor-model side of things 👍 .

[lcgamboa]

Thanks for the answer. It was clear to me all the steps.
I think using PicoRV32 in the RV32IMC version could be a start. I have knowledge about programming simulators in C/C++ and microcontrollers, but I only know the basics about riscv and hdl.
To implement this support for the C extension in Ripes would be necessary which knowledge mainly? C/C++, HDL, VSRTL?
Depending I could directly help with the implementation. If the implementation is in C/C++ I could study the implementation that Spike simulator uses to expand/decode the instructions and do something similar. If it's in HDL I can study PicoRV32, but it would take longer.
As I don't have much knowledge of Ripes' inner workings, I cannot assess the difficulty of this implementation. But from your previous answer it seems to be something possible, but complex for you to implement.

[mortbopet]

it seems to be something possible, but complex for you to implement

It's definitely possible! its just about putting the work in 😛. I'd say in general, the two things that are needed is knowledge of C++ (due to Ripes being based on that) + general HDLs. VSRTL defines it's own language/api for describing the processor models. Writing the models through this language should be quite familiar to anyone who's worked with HDLs before. As a starting point, i'd invite you to take a look at the single cycle processor and the instruction decode component. In general, i'd say the level of complexity of the processor models is lower than "real" cores.

The assembler itself is based on describing the meta-information about an instruction, which then gets used to generate a parser, assembler and disassembler for an instruction. As an example, the load instructions are defined here:

Ripes/src/assembler/rv32i_assembler.h

Lines 289 to 293 in d692d71

	instructions.push_back(LoadType(Token("lb"), 0b000));
	instructions.push_back(LoadType(Token("lh"), 0b001));
	instructions.push_back(LoadType(Token("lw"), 0b010));
	instructions.push_back(LoadType(Token("lbu"), 0b100));
	instructions.push_back(LoadType(Token("lhu"), 0b101));

Which uses the following macro:

Ripes/src/assembler/rvassembler_common.h

Lines 29 to 33 in d692d71

	#define LoadType(name, funct3) \
	std::shared_ptr<_Instruction>( \
	new _Instruction(_Opcode(name, {_OpPart(RVISA::Opcode::LOAD, 0, 6), _OpPart(funct3, 12, 14)}), \
	{std::make_shared<_Reg>(isa, 1, 7, 11, "rd"), std::make_shared<_Reg>(isa, 3, 15, 19, "rs1"), \
	std::make_shared<_Imm>(2, 12, _Imm::Repr::Signed, std::vector{_ImmPart(0, 20, 31)})}))

At first glance it may look quite messy, but i think (hope) that if you correlate that with the description of the load instructions in the RISC-V ISA manual, you'll quickly see the equivalence.

[mortbopet]

In any case, i'm always available if you have any questions about getting things up and running, the codebase or design ideas! 👍 .

Finally, I've also been toying with the idea of using Verilator generated processors as a backend for Ripes. With the current mechanism (using VSRTL), we get the added benefit of a visualization. However, VSRTL is not a fully-fledged HDL and users may find it difficult to express some constructs in it. As an experiment, i've toyed with adding support for a verilated PicoRV32 processor in Ripes. The process is described here: https://github.com/mortbopet/Ripes/wiki/Adding-new-processor-models#experimental-verilator-processor-models-in-ripes

[mortbopet]

I am looking into adding support for the C extension in the assembler, at the moment. There's some larger changes that needs to be made to the assembler/disassembler infrastructure to be able to handle mixed instruction widths.

[lcgamboa]

I am studying ISA and I believe that modifying the decoder and Imm blocks to support the modified instructions is not that complex. I believe that keeping RVC support always on will not influence code simulation without 16-bit instructions. I plan to start implementing the c.nop statement initially.
I have a question, if I load a binary flat file with RVC instructions can I simulate the modified blocks independently of modifying the support in the disassembler? Or is it integrated with blocks? Don't be in a hurry to implement this support if you have other tasks to do.

[mortbopet]

if I load a binary flat file with RVC instructions can I simulate the modified blocks independently of modifying the support in the disassembler?

In theory, yes. The disassembler should just emit an "unknown instruction" string - I've never tried it, though! so let me know how it goes.

Don't be in a hurry to implement this support if you have other tasks to do

I have a bit of free time today, so I'll be trying to knock out some initial support for this :).

[mortbopet]

The https://github.com/mortbopet/Ripes/tree/c_ext branch contains preliminary support for a few of the compressed instructions:

Ripes/src/assembler/rv_c_ext.h

Lines 30 to 35 in 957eb95

	instructions.push_back(CAType(Token("c.and"), 0b11, 0b100011));
	instructions.push_back(CAType(Token("c.subw"), 0b00, 0b100111));
	instructions.push_back(CAType(Token("c.addw"), 0b01, 0b100111));
	instructions.push_back(CAType(Token("c.or"), 0b10, 0b100011));
	instructions.push_back(CAType(Token("c.xor"), 0b01, 0b100011));
	instructions.push_back(CAType(Token("c.sub"), 0b00, 0b100011));

There remains a few issues wrt. the disassembled view in both the editor and processor tab. But, you should be able to write C instructions as well as mix compressed and regular instructions.

Let me know if it works for you - hopefully it'll make your experimentation a bit easier!

[lcgamboa]

Thanks for the help, of course it will make it much more easier.
When only a 16-bit instruction is used, a misalignment error appears in editor, if I understand correctly the ISA documentation in practice the alignment should be 16 bits instead of 32 to increase compression. But for now your modifications are more than enough to start the implementation. As I need to study the ISA more and better understand the inner workings of Ripes, I'm developing more slowly.
Thank you very much for the support.

[mortbopet]

Hmm, what exactly is your source code? The emissions should start at 0x0, hence always 16-bit aligned. Aligned errors only occurs when we do i.e.:

c.and a0 a0
nop

Code like the following should work:

[lcgamboa]

The error appears placing only one RVC instruction, placing multiples of 2 works. That's not critical for now.

From the ISA documentation :

We use the term IALIGN (measured in bits) to refer to the instruction-address alignment constraint
the implementation enforces. IALIGN is 32 bits in the base ISA, but some ISA extensions, including
the compressed ISA extension, relax IALIGN to 16 bits. IALIGN may not take on any value other
than 16 or 32.

[mortbopet]

Looks like I didn't read the spec closely enough - I was under the impression that the compiler (in our case, programmer) had to manually insert a c.nop instruction to align the instruction counter. Thank you for highlighting this! 👍 .

[lcgamboa]

Initially I thought this way too, but to increase the compression the alignment is reduced from 32 to 16. But you don't need to worry about that now, to support it will probably need a lot more changes. The changes you've already made are more than enough for me to start implementing. I can use some c.nop to align without problems.

[mortbopet]

I've added #125 to track the progress of all of this; feel free to raise new issues and add them into that tracking issue.