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.