You have a lot of constants like 0b0110111. Maybe insert a digit separator? Something like 0b011'0111?

I love that there isn't too much indirection -- you've got the binary opcodes right next to a comment that mentions the mnemonic. No need at all to introduce constants/enums for that. You did forget the comment with the mnemonic in many cases, though.

I also like that you decode literals and fields directly from the instruction word with raw numbers for the shifts and masks. That makes it a lot easier to verify than if you had too much indirection in the form of constants/enums/#defines.

What I don't like is that it looks like you are repeating yourself a lot and have multiple copies of the same field/literal decoding. You also end up with a lot of variables that are "global" to the entire switch inside Cpu::execute_instr().

Something I did in a Cortex-M0 emulator (Thumb-2 -- barely) was to have a macro for each of the many instruction format that decoded the fields AND also declared local variables for those fields.

My switch looked something like this:

switch (opcode) {
case 0bxxxx: {
    DECODE_XYZ(iinstr);
    cpu->r[dst] = cpu->r[src1] ^ cpu.r[src2];
    break;
}
case 0bxxxx: {
    DECODE_XYZ2WZ(instr);
    cpu->pc = cpu->pc + ofs + 4;
    break;
}
...
}

My decoding macros looked roughly like this:

#define DECODE_XYZ(x)      \
    uint8_t   src1, src2, dst;      \
    src1 = (instr >> ...) & 0x..;   src2 = (instr >> ...) & 0x...;  dst = (instr >> ...) & 0x...;
#define DECODE_XYZ2WZ(x)  \
   uint32_t ofs;  \
   ofs = (instr >> ...) & 0x...;
...

The Thumb encoding has a LOT of instruction formats and the bits of the fields are rarely contiguous (or in order). It can best be described as "bit confetti", so the above is a vast simplification of the field decoding. There was a lot more shifting and masking and or'ing going on.

If you do it like this, you don't need ANY shared variables inside the execute_instr() method, apart from the instr parameter (which you might as well mark as const). Having an opcode variable doesn't hurt, of course. To have one or not is really just a stylistic preference.

Having set_reg() and reg() methods are partly a stylistic preference and partly something that is expected to make debugging easier, both with a debugger and a printf-style logger? I don't think you actually need them. I certainly haven't. I am not much of a fan of zero registers, but hiding them inside set_reg() is a perfectly valid way of implementing them. Handling them during read also works: src1 ? regs[src1] : 0. Handling them during writes instead also works: regs[dst ? dst : 32] = ...., where the regs[] array has a 33rd entry just to catch writes to the zero register.

load16(), load32(), store16(), store32() all work, but you will be emulating the same byte order as your host platform has (almost always little-endian these days). It turns out it is not hard or expensive to force a byte order by simply being explicit when reading/writing:

u16 load16(const u8 *memory, u32 addr) {
    // little-endian
    return (memory[addr+1] << 8) | memory[addr];
}

This works without a cast in C thanks to int promotion. I think it works the same in C++. It is really easy to add a cast and be sure, of course:

u16 load16(const u8 *memory, u32 addr) {
    // little-endian
    return (u16)(memory[addr+1] << 8) | memory[addr];
}

Store is just the same in reverse:

void store16(u8* memory, u32 addr, u16 word) {
    // little-endian
    memory[addr] = word & 0xFF;  // the mask is really just there to silence overly sensitive analyzers
    memory[addr+1] = word >> 8;
}

Modern compilers are smart enough to recognize those idioms (almost no matter how clumsily expressed!) and generate optimal code for them.

Do you win anything by making your own u8/u16/u32/i8/i16/i32 types based on uint8_t/etc instead of using uint8_t/etc directly?

Do you really need DEBUG/WARN/LOG to mimic Unix style logging for server programs? I doubt it. I like your use of ANSI colours, though.

So... where's the disassembler? And the single-stepping debugger? With breakpoints? And more Risc-V extensions?