[libre-riscv-dev] [Bug 264] ISA switch needs to be a privileged operation

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=264

--- Comment #1 from Jacob Lifshay <programmerjake at gmail.com> ---
What could work is to have new ELF flags to indicate which ABI variants a
particular executable, object (.o file), or dynamic library requires. The
dynamic linker and standard linker would make sure that the files are
compatible.

This is kinda similar to what RISC-V is doing:
see e_flags field in
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

Defining which ISAs can link together and if inlining can occur should be the
responsibility of the toolchain and dynamic linker, rather than relying on ISA
switching being a privileged operation.

What I think should happen is that the ABI requires functions to have the ISA
set to the proper value when calling a function, and if it isn't set properly,
then that's a bug in the calling function. Likewise for returning.

This is similar to how the thread pointer or stack pointer must be set properly
before calling a function. If it isn't set properly, than it's undefined
behavior and the code is allowed to do anything (though will probably crash).

I had been planning on the actual RISC-V/Power ISA switching operation happen
as part of switching between user and kernel modes, where all the RISC-V state
is accessible in either standard Power registers or SFRs.

For switching between standard Power and Power+SVPrefix, I was hoping that all
of SVPrefix would just fit in unallocated portions of the Power ISA.

For handling 16-bit instructions, would it work to instead define a pair of
16-bit instructions as a 32-bit instruction with the standard opcode field in
the correct position for decoding to allow mixing with arbitrary >= 32-bit
Power ISA operations?

For example, if there were the following two 16-bit instructions:

add 3, 3, 4
addi 3, 3, 12

They would both be packed into
a single 32-bit instruction (denoted using braces):

{
    add 3, 3, 4
    addi 3, 3, 12
}

We wouldn't need to support all instructions, just the most common ones, and
it's perfectly fine to not support particular pairs (such as if the second one
can trap and the first one can't just be run again -- allowing us to not need
to worry about what happens if we trap in the middle of a pair).

-- 
You are receiving this mail because:
You are on the CC list for the bug.