definition of SC instruction with X0 as the destination register

[chuanhua.chang]

What is the definition of SC instruction with X0 as the destination register?

Is it a NOP operation? or an illegal instruction that generates an exception?

Thanks!

Chuanhua Chang

[Andrew Waterman]

It is a legal instruction, but probably not very useful. Most
implementations will execute it the same way as a normal SC: in other
words, the store may or may not be performed. It's not quite legal to
execute it as a NOP, because you still need to check the address and
raise an exception if the address is invalid.

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/08667117-9750-4e8c-9d61-548c1a319f6a%40groups.riscv.org.

[chuanhua.chang]

It is not useful at all since it always indicates a failed store operation no matter it stores data successfully or not. So SW will never use this instruction. Under this condition, why not define it as a NOP operation or an illegal instruction?

Chuanhua

[Andrew Waterman]

On Tue, Nov 14, 2017 at 4:56 AM chuanhua.chang <chuanhu...@gmail.com> wrote:

It is not useful at all since it always indicates a failed store operation no matter it stores data successfully or not. So SW will never use this instruction. Under this condition, why not define it as a NOP operation or an illegal instruction?

Because that would slightly complicate the HW by adding a special case.

Chuanhua

[Alex Elsayed]

Because then software would be allowed to _rely_ on it being a NOP, or it
raising an illegal instruction exception (and before you say "nobody would do
that", obfuscation for the sake of detecting virtualization or debuggers _is_
a thing people do).

You may be intending your proposal as "if this doesn't make sense, we should
ban it, and then nobody needs to handle it" but that's not how this works.
Your proposed behaviors _do not_ remove the need for hardware to handle that
operation, merely change what the result must be - and the result you propose
is one that is _more_ costly for hardware.

[Samuel Falvo II]

It can't be a NOP, because the reservation can still hold and a write
*can* (thus) still occur. Just because you ignore the status result
doesn't mean you intend to ignore the conditional store semantics
completely.

If you really wanted to catch this in hardware as a possible error
condition, you'd would have to take an illegal instruction trap.
That's the only viable thing you can do.

> You may be intending your proposal as "if this doesn't make sense, we should
> ban it, and then nobody needs to handle it" but that's not how this works.

I don't read it that way, and I don't think Andrew is reading it that
way either. Whether or not a SC X0 instruction makes sense depends on
the application this instruction is found in. Detecting every
possible instruction combination that *could* *maybe* lead to
ambiguity is a fools' errand, and I feel it's worthy of an extension,
but not of a base-level specification.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3121670.Vjo49BUr6N%40arkadios.



--
Samuel A. Falvo II

[chuanhua.chang]

The "NOP" operation I described for the "SC with X0" instruction really means no operation. It will not do any operation related to "store conditional" at all. It is treated as a completely different instruction than "SC". To implement this definition/behavior may cost more decoding logic, or even affect the maximum frequency of an RV core. But this is an architecture definition trade-off. For example, if I want to use it as a NOP-hint instruction to communicate some software information to hardware. Another example is if instruction encoding space is not enough and I want to preserve this useless instruction encoding for future instruction extension, it would be better to define it to generate an illegal instruction exception for the baseline ISA.

I agree that implementing it as a normal SC will probably cost the least for hardware and maximum frequency target. But sometimes, hardware cost is not the only concern. There may be other architecture design goals that needs to be fulfilled.


Chuanhua

[Samuel Falvo II]

On Thu, Nov 16, 2017 at 6:55 AM, chuanhua.chang
<chuanhu...@gmail.com> wrote:
> The "NOP" operation I described for the "SC with X0" instruction really
> means no operation. It will not do any operation related to "store
> conditional" at all. It is treated as a completely different instruction
> than "SC".

It is at this point that RISC-V stops being RISC and turns into a
CISC. I'm going to say hard-no to this idea.

The 68000 was *rife* with these kinds of special-cases, and for
precious little gain. Programmers (especially compiler authors)
*hated* it. I can tell you now I definitely hate this idea.

> To implement this definition/behavior may cost more decoding
> logic, or even affect the maximum frequency of an RV core. But this is an
> architecture definition trade-off. For example, if I want to use it as a
> NOP-hint instruction to communicate some software information to hardware.

There are literally at least 15 other possibilities, all currently
explicitly defined as no-operations, which you can use off the top of
my head for this task that does not require special-casing SC X0:

SLLI X0,X0,0
SLL X0,X0,X0
SRLI X0,X0,0
SRL X0,X0,X0
ANDI X0,X0,0
AND X0,X0,X0

and so forth.

> Another example is if instruction encoding space is not enough and I want to
> preserve this useless instruction encoding for future instruction extension,

RISC-V has several rather significantly huge chunks of its 32-bit
opcode space explicitly reserved for exactly this purpose. If this
doesn't work, you can extend the opcode size in increments of 16 bits
to get even more custom opcode space.

> it would be better to define it to generate an illegal instruction exception
> for the baseline ISA.

No. Even though I advocated trapping over special-casing (and even
then, only as part of an ISA extension), I argue not only will it not
be useful, but it would forever mar the face of RISC-V for everyone,
implementers and users alike. Under no circumstances would redefining
the SC X0 instruction benefit anyone, not even security-minded
(black-hat or white-hat) folks.

The reason is simple:

SC X0,X1,X2

is semantically exactly the same thing as:

SC X1,X2,X3

where X1 is subsequently a dead register and (perhaps immediately) re-used.

Trapping SC X0 is a false endeavor here.

Defining this instruction as a "NOP hint" is also worthless, as I
illustrated above, where we have 15 other *officially sanctioned* NOPs
to choose from which currently serve no other useful purpose, and
that's *without* looking into opcode space explicitly reserved for
extensions.

I may not be as important as anyone else on this list; yet, as a
RISC-V implementer (and I am one), I am *not* going to pay the
hardware cost for a useless feature. Compared to stack architecture
CPUs, RISC-V is damn expensive in area and power as it is. I'm not
making it worse. If RISC-V standardized anomalous behavior for SC X0,
I'm going on record here and now saying that I'm going to utterly
ignore that standard as frivolous.

> I agree that implementing it as a normal SC will probably cost the least for
> hardware and maximum frequency target. But sometimes, hardware cost is not
> the only concern. There may be other architecture design goals that needs to
> be fulfilled.

RISC-V was built with these already in mind. Use those features. I
ask that people please not walk all over what is otherwise a pure,
clean design. Do not turn RISC-V into CISC-V. The 68000 did it
because it had a virtually exhausted 16-bit opcode space on the first
day it shipped. RISC-V explicitly intended not to have this happen.