[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 #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #1)

i'll mention the elf flags idea. it may help at some point if you could explain
it to Tim of RaptorCS.


> 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.

just. barely, yes. by using up 2 major opcodes per prefix.  2 for 48, 2 for 64
bit.

> 
> 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?

only on BE systems because only then does the decoder see the major opcode in
the 1st byte.

ok ok if we wanted to make ourselves feel like jamming our fingers down our
throat and hurling, we could go:

"ok mr 32 bit LE system, we have reserved 2 major opcodes for C, and in byte 3
we have a C instruction.  however there are 2 bytes left, 0 and 1, which is now
the SECOND C instruction, to be executed AFTER the one in bytes 2 and 3".

if those 2 bytes are all zero that is a C NOP

so this would mean running instructions in a weird 2 steps forward, 1 step back
fashion, but would at least be LE compatible.

blech.

SVPrefix32 (C with a SVP added) is also doable btw.  that just takes up 32
bits, straight.

> 
> 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, 

yes agreed.  i'd like to ask rogier bruisse to help design it, he is extremely
good.



>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).

hmm... we might have to. or, another way (indicating the extent of the
awfulness), a bit in a SPR which is contextswitched tells us which of the 2 C
instructions are being executed.

or... *shudder* we have the PC advance first by 4 bytes, then jump BACK 2
bytes, then jump forward to... no, my brain just melted thinking about that
one.

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