No. This is like asking if a 6502 microprocessor can run a 6809’s code because they’re both 8-bit micros.

The family of instruction sets under the RISC-V banner is completely different from the family of instruction sets under the ARM banner. I’ll compile this program for RISC-V and ARM and show you the compiler outputs for an example:

#include 
int main(int argc, char** argv)
{
    printf("Hello, world!");
}

First ARM (a fairly generic ARM32 processor core’s output):

.LC0:
        .ascii  "Hello, world!\000"
main:
        push    {r7, lr}
        sub     sp, sp, #8
        add     r7, sp, #0
        str     r0, [r7, #4]
        str     r1, [r7]
        movw    r0, #:lower16:.LC0
        movt    r0, #:upper16:.LC0
        bl      printf
        movs    r3, #0
        mov     r0, r3
        adds    r7, r7, #8
        mov     sp, r7
        pop     {r7, pc}

Now RISC-V (again a fairly convention 32-bit RISC-V core):

.LC0:
        .string "Hello, world!"
main:
        addi    sp,sp,-32
        sw      ra,28(sp)
        sw      s0,24(sp)
        addi    s0,sp,32
        sw      a0,-20(s0)
        sw      a1,-24(s0)
        lui     a5,%hi(.LC0)
        addi    a0,a5,%lo(.LC0)
        call    printf
        li      a5,0
        mv      a0,a5
        lw      ra,28(sp)
        lw      s0,24(sp)
        addi    sp,sp,32
        jr      ra

Comparing the two you’re going to note several very major differences. One of the biggest and easiest to spot, however, is how ARM pushes r7 and lr onto the stack at the beginning, but pops r7 and pc at the end. This is because lr contains the “return address” (it’s a bit more complicated than that, but close enough for jazz) on entry and pc is the “program counter” which is where the processor will get its next instruction from. By popping what was the lr value into pc you’ve effectively done a transfer of control to the return address without an explicit branch.

RISC-V, conversely, uses ra (their equivalent of lr) pushed onto the stack (note how each value is pushed manually, not part of a combined instruction), then popped back from the stack and an explicit jr branch instruction is used to set the next instruction to be executed. So even ignoring the different names of instructions (which could just be different naming conventions for the same thing), the very way the two systems operate is very different.

So while ARM and RISC-V are both RISC processors, they are not even similar to each other in operations beyond both following the RISC philosophy of instruction set design.

RISC is just a design philosophy, ARM and RISC-V are different command sets (opcodes) and software will have to be recompiled to run on it without emulation, which would be slow.

Think of it like languages. Both Japanese and English can describe an apple, but the actual words are dramatically different.

A good thing is that with the ARM revolution people have gotten used to building and debugging code that can build on both x64 and ARM, so being able to build and run on RISC-V is like learning a third (or fourth language if you include going from x86 to x86-64) and anyone who’s learned languages will tell you each one is easier to learn than the last. It will take less time for developers to have RISC-V build targets in theory.

Developers are working hard to rebase apps to run on RISC-V silicon. There seem to be a good number of open source apps already available, though I haven’t seen a definitive list anywhere. I use the Alpine Linux repository to monitor progress : https://pkgs.alpinelinux.org/packages?name=&branch=edge&repo=&arch=riscv64&maintainer=

Building for RISC-V also means updating compilers to target RISC-V. Optimizations that are available on x86 may not be the same as what is available as on RISC-V platforms, so it may take a while for performance and support to improve.