Force emission of uncompressed ebreak? (Equivalent to ARM's width specifiers?)

[Pat Pannuto]

Hi folks,

We've run into a situation with the Tock project where we need to prevent to coercion of an `ebreak` to a `c.ebreak` instruction.

In particular, when running in a semihosting setup, following https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc#11-semihosting-trap-instruction-sequence, the trap sequence requires very specifically the full ebreak.

However, when using inline assembly with Rust, i.e.,

    asm!(

        "slli x0, x0, 0x1f

         ebreak

         srai x0, x0, 7" );

if the underlying machine supports compressed instructions, this will (correctly, I believe) be automatically converted to the compressed ebreak during compilation.

In ARM, the ISA has "width specifiers" for situations where multiple encodings are valid but the assembly-writer needs a specific one (i.e. "mov.n r0 r0 r0" and "mov.w r0 r0 r0" are 16 and 32-bit encodings, respectively).

Does RISC-V have a similar means to force the emission of the uncompressed variant? If not, would it be reasonable to consider adding one?

Currently we work around this by having a separate, short assembly file that is processed by a separate make step that invokes the assembler with a specified machine that does not support compression; we then link in this object to the regular build. This works, but we would like to get rid of all these extra steps if we can.

Context and current workaround is here: https://github.com/tock/tock/pull/2599

Thanks!

-Pat

[Palmer Dabbelt]

On Tue, 15 Jun 2021 08:41:43 PDT (-0700), ppan...@eng.ucsd.edu wrote:
> Hi folks,
>

> We've run into a situation with the Tock project where we need to *prevent*

This is more of a sw-dev question than an isa-dev question.

".option norvc" will do this for you. You generally want to push/pop
the option stack to avoid that bleeding into the rest of your file,
here's an example of how we do it in Linux (where we also disable linker
relaxation, as we're looking for bit-exact sequences):
https://elixir.bootlin.com/linux/v5.12.10/source/arch/riscv/include/asm/jump_label.h#L21

There are a few common instructions that users don't want compressed,
generally NOP and EBREAK. We've kicked around the idea of adding
explicitly non-compresed versions of those. I wouldn't be opposed to
adding these, but in practice whenever I've ended up needing these I end
up with a bunch of other constraints on the assembly (alignment, no
relaxing, etc) that will result in a multi-line sequence anyway so the
option pop/push really isn't that big of a deal.

[Pat Pannuto]

The option push/pop looks like it works great, thanks!

For production software, I think you're right that the option series will generally be more useful. Indeed, we likely needed (and I added) the norelax here as well.

The only other scenario I use the ARM width specifiers is a bit more contrived, namely live-coding in lectures. I've demoed PC-relative addressing and jumps, with toy examples, and there it's really valuable to be able to be certain about instruction sizes, so I'll tack on the width specifiers to everything, even when they aren't needed. That's not exactly a general-purpose case, but it is useful to have to option to be explicit. In that context, it's worth noting that Thumbv2 does allow the ".n" and ".w" specifiers on every instruction (i.e. even those that only ever have wide encodings). Pedagogically, it's a useful stepping stone to be able to explicitly show the size of every instruction at the source level when folks are first starting. Then we can drop the width specifiers once folks get more comfortable with how most instructions are sized. I bring this up not as a strong case for needed width specifiers in RISC-V, but as a nudge that if you do add them, it would be nice to add them as a general feature, rather than tied for a few, specific instructions.

Sorry for hitting the wrong list.

-Pat

[Robert Lipe]

On Tuesday, June 15, 2021 at 11:56:44 AM UTC-5 ppan...@eng.ucsd.edu wrote:

source level when folks are first starting. Then we can drop the width specifiers once folks get more comfortable with how most instructions are sized. I bring this up not as a strong case for needed width specifiers in RISC-V, but as a nudge that if you do add them, it would be nice to add them as a general feature, rather than tied for a few, 

I can see that, but if you're teaching isn't assigning the width to every opcode just kind of a distraction? The .n and .w nomenclature just seems to add mental noise that doesn't really lend itself to what you're (presumably) trying to teach, doesn't it? I know that when I'm reading code, I've always found it distracting.

I'd code everything in uncompressed RV32 or RV64. Everything is then naturally aligned, it's conveniently one word per opcode, and the trap handlers are dead easy.

Most developers can go a long way before they even have to learn about compressed opcodes. Sure, it has advantages, but in a whiteboard/teaching environment, just having a consistent opcode size seems worth it.

Of course, only you know what you're trying to teach (or code)  and it's not my job to pitch you on a different approach but I'm offering a more distant view and wondering if you should be doing compressed opcodes - at all - in the kind of environment you're describing.

novrc is a cool tip to keep in mind, though. Thanx for that!

[Pat Pannuto]

At the time, it was on a Cortex-M platform, so mixed-width instructions came with the territory. If I were to do the same with RISC-V, I agree, I would probably try to avoid the complexities of compression.

Nonetheless, the point was simply to identify that having the option/capability to be clear/explicit can be valuable in certain situations.