Public review for standard extensions Zba, Zbb, Zbc, Zbs

[Krste Asanovic]

We are delighted to announce the start of the public review period for
the following proposed standard extensions to the RISC-V ISA:

Zba - address generation
Zbb - basic bit manipulation
Zbc - carryless multiplication
Zbs - single-bit instructions

These are the first four extensions of the Bitmanip specification to
enter public review. Further Bitmanip extensions are expected to
follow at a later date.

The review period begins today, Friday June 11th, 2021, and ends on Monday
July 26th (inclusive).

These extensions are described in the PDF spec available at:

https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0

which was generated from the source available in the following GitHub repo:

https://github.com/riscv/riscv-bitmanip

To respond to the public review, please either email comments to the
public isa-dev mailing list or add issues and/or pull requests (PRs)
to the public github repo above. We welcome all input and appreciate
your time and effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Bitmanip task group.
Any minor corrections and/or uncontroversial changes will be
incorporated into the specification. Any remaining issues or proposed
changes will be addressed in the public review summary report. If
there are no issues that require incompatible changes to the public
review specification, the unprivileged ISA committee will recommend
the updated specifications are approved and ratified by the RISC-V
Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Krste
(Chair, Unprivileged ISA Committee)

[Iztok Jeras]

Is there a plan to provide a set of test to https://github.com/riscv/riscv-arch-test

It would help with the implementation end thus review.

Iztok

[Sean Halle]

Thank you for this.  It represents a lot of work by many.

I am curious about one aspect of the implementation that I don't have a good read on, by just examining the instruction definitions..  which is potential complications in the pipeline.

Would there be, by any chance, some meeting minutes or notes around somewhere that discuss implementation details?  

In particular, I'm wondering about the impact on deep pipelines with aggressive clock targets.  

For example, things like counting set bits, and carryless multiply reversed, feel, at first impression, as though they may require large hardware to meet an aggressive clock target (and also maintain good IPC), and may cause complications in a deep pipeline.  

(It wasn't clear whether these instructions also allow designating 8b, 16b, or 32b operand size, but adding that flexibility to these seems as though it could increase the impact on the implementation).

Another area is forwarding in a deep pipeline, combined with handling an exception.  There are often subtle bugs that pop up that aren't apparent just from trying to visualize things in your head..  they only manifest in rare cases while running large applications or doing fuzz testing in FPGA.  Some of these extensions feel as though they may be fertile ground for such.  These kinds of bugs are always fixable, but the fix, often, is awkward and ends up in the critical path, which slows the clock, or else causes large hardware.

Have there been implementations in complex pipelines that would supply comfort on this?  Especially with layout to see cycle time and gate count implications?  

If so, would there be any chance to share?

Thanks,

Sean

--
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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/m2pmwsotq6.fsf%40berkeley.edu.

[kr...@berkeley.edu]

These are common instructions that have been implemented in commercial
high-frequency cores. In a deep pipeline, some of these instructions
would be more deeply pipelined and have >1 cycle latency, but are no
more difficult to handle than an integer multiply, for example.

Krste

[Allen Baum]

That's an excellent analogy - if we can deal with multiply (let's not even go into divide) we can easily deal with these.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/24775.11149.340258.212293%40KAMacbookPro2016.local.

[Jeff Scott]

I believe there is a typo for ROL:

let result = (X(rs1) << shamt) | (X(rs2) >> (xlen - shamt));

should be:

let result = (X(rs1) << shamt) | (X(rs1) >> (xlen - shamt));

Same for ror, rori.

Jeff

-----Original Message-----
From: Krste Asanovic <kr...@berkeley.edu>
Sent: Friday, June 11, 2021 6:41 PM
To: isa...@groups.riscv.org
Subject: [EXT] [isa-dev] Public review for standard extensions Zba, Zbb, Zbc, Zbs

Caution: EXT Email

We are delighted to announce the start of the public review period for the following proposed standard extensions to the RISC-V ISA:

Zba - address generation
Zbb - basic bit manipulation
Zbc - carryless multiplication
Zbs - single-bit instructions

These are the first four extensions of the Bitmanip specification to enter public review. Further Bitmanip extensions are expected to follow at a later date.

The review period begins today, Friday June 11th, 2021, and ends on Monday July 26th (inclusive).

These extensions are described in the PDF spec available at:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-bitmanip%2Freleases%2Ftag%2F1.0.0&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7C73940e6f98b84093ebb108d92d325ac2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637590516565174596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=RSVdHAlUsmkCvyhQm5rz8zlTjGjqquF3RgJvSqO9%2FH0%3D&amp;reserved=0

which was generated from the source available in the following GitHub repo:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv%2Friscv-bitmanip&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7C73940e6f98b84093ebb108d92d325ac2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637590516565174596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=283sJ8%2BaJqgzORH1TSRM4gKrQVq39TY8DsFw1AI%2FvxE%3D&amp;reserved=0

To respond to the public review, please either email comments to the public isa-dev mailing list or add issues and/or pull requests (PRs) to the public github repo above. We welcome all input and appreciate your time and effort in helping us by reviewing the specification.

During the public review period, corrections, comments, and suggestions, will be gathered for review by the Bitmanip task group.
Any minor corrections and/or uncontroversial changes will be incorporated into the specification. Any remaining issues or proposed changes will be addressed in the public review summary report. If there are no issues that require incompatible changes to the public review specification, the unprivileged ISA committee will recommend the updated specifications are approved and ratified by the RISC-V Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Krste
(Chair, Unprivileged ISA Committee)

--
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 view this discussion on the web visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fgroups.riscv.org%2Fd%2Fmsgid%2Fisa-dev%2Fm2pmwsotq6.fsf%2540berkeley.edu&amp;data=04%7C01%7Cjeff.scott%40nxp.com%7C73940e6f98b84093ebb108d92d325ac2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637590516565174596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=SqFDSKg3NvIh1MqZlxU2jGuS%2FLmBTgEfbHA6r1oMGJU%3D&amp;reserved=0.

[Anna Slobodova]

Jeff, you are right and it has been documented in issue #143. The fix is on its way.

[Jeff Scott]

Thank you Anna.  Any insight why it was chosen to use opcode space for a right and left rotate?  What was the thought process there?

 

Jeff

[Andrew Waterman]

On Tue, Jun 15, 2021 at 7:51 AM Jeff Scott <jeff....@nxp.com> wrote:

Thank you Anna.  Any insight why it was chosen to use opcode space for a right and left rotate?  What was the thought process there?

For the immediate-operand variant, only rotate-right is provided, since the rotate amount can just be statically negated.

For the register-operand variant, both are provided to avoid a negation instruction.  Both show up in application code, and providing the other is very cheap if you already provide the rest of the shifts and rotates, so it's easily justified.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/PA4PR04MB750230FDC3FB3FE75DCC36798D309%40PA4PR04MB7502.eurprd04.prod.outlook.com.

[Jeff Scott]

Thanks for the response Andrew.

 

I think you are saying if only one direction of rotate is supported, the complier will have to generate more code for some algorithms than if both directions of rotate are supported.  This is surprising to me.  Which compiler did you see this in?  PowerPC and Arm both support only one direction AFAIK.

 

Jeff

[Andrew Waterman]

On Wed, Jun 23, 2021 at 2:36 PM Jeff Scott <jeff....@nxp.com> wrote:

Thanks for the response Andrew.

 

I think you are saying if only one direction of rotate is supported, the complier will have to generate more code for some algorithms than if both directions of rotate are supported.  This is surprising to me.  Which compiler did you see this in?

It isn't about choice of compiler.  Fundamentally, if the ISA provides only rotate-right-by-variable, and the program semantics call for a rotate-left-by-variable, then negating the rotate amount is necessary.  But, for a concrete example, look at this ARMv8 example compiled with GCC:

https://godbolt.org/z/dafc6eTqE

  PowerPC and Arm both support only one direction AFAIK.

By contrast, x86 provides both; analogous example is here: https://godbolt.org/z/o54jnqo6x

[Jeff Scott]

Thanks!  But your taking one “amt” and trying to rotate both ways with that amt.  So, it’s not surprising you will end up with negation on one.  I wonder if “amt” is tuned to the direction supported and all code uses that direction in PowerPC and Arm compilers?

[Samuel Falvo II]

On Wed, Jun 23, 2021 at 12:36 PM Jeff Scott <jeff....@nxp.com> wrote:

I think you are saying if only one direction of rotate is supported, the complier will have to generate more code for some algorithms than if both directions of rotate are supported.  This is surprising to me.

Consider a single byte for simplicity.  Let's give it a value of 10010110 (0x96).  Rotate right by one bit w/out carry, and you get 01001011.  Rotating left by one bit, you get 00101101.

But, if you rotate *right* by 7 bits, you end up with 00101101 as well.

    10010110 (rotation by 0)

    01001011 (rotation by 1)

    10100101 (rotation by 2)

    11010010 (rotation by 3)

    01101001 (rotation by 4)

    10110100 (rotation by 5)

    01011010 (rotation by 6)

    00101101 (rotation by 7)

    10010110 (rotation by 8)

In other words, rotation left is equivalent to rotation right by 8-n bits, where n is the desired number of bits to rotate.  Hence, the "negation" that was mentioned.  7 is -1 in 2's complement, 3-bit field.

So, if you want to rotate by a constant number of bits (in either direction), you can always express rotate left in terms of rotate right, and vice versa.  They're isomorphic to each other.  The direction of rotation and the distance of displacement can be statically expressed in the immediate field.

Separate rotate left and right instructions becomes more useful when the amount you wish to rotate by is *not* a constant.  In this case, having a separate instruction is faster than dynamically computing a rotation amount.

--

Samuel A. Falvo II

[Andrew Waterman]

On Wed, Jun 23, 2021 at 3:04 PM Jeff Scott <jeff....@nxp.com> wrote:

Thanks!  But your taking one “amt” and trying to rotate both ways with that amt.  So, it’s not surprising you will end up with negation on one.  I wonder if “amt” is tuned to the direction supported and all code uses that direction in PowerPC and Arm compilers?

That's just an idiom [1] for expressing rotates in C, since there isn't a native rotate operator in that language.  If you use the new std::rotr and std::rotl operators in C++20 (which you can't currently do on godbolt), you'll see the same thing.  It's fundamental to the operation and has nothing to do with compiler optimization.

[1] A bad idiom, since it has undefined behavior when amt=0.

[Jeff Scott]

Thanks for all the feedback!

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0BkC2r7kNiZ9mp-LHj24WY%3DAdS%3D_w_f_7hDXqqdEsh%3DEg%40mail.gmail.com.

[Craig Topper]

Clang does have __builtin_rotateleft32 and __builtin_rotateright32, as well as 8, 16, and 64.

In some cases the compiler might be able to find a freely negatable operation to merge the negate with. Clang did better than gcc for my simple test https://godbolt.org/z/sbcoa14ca

~Craig

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0BkC2r7kNiZ9mp-LHj24WY%3DAdS%3D_w_f_7hDXqqdEsh%3DEg%40mail.gmail.com.

[Jeff Scott]

A couple more questions.

 

1. Is there plans for compressed variants of these instructions?
2. Why no 0-extend byte?

 

Thanks,

 

Jeff

[Andrew Waterman]

On Wed, Jun 30, 2021 at 12:48 PM Jeff Scott <jeff....@nxp.com> wrote:

A couple more questions.

 

1. Is there plans for compressed variants of these instructions?

That's something we expect to study in the future.

2. Why no 0-extend byte?

The andi instruction already provides this functionality.

[Craig Topper]

On Jun 30, 2021, at 1:01 PM, Andrew Waterman <and...@sifive.com> wrote:

On Wed, Jun 30, 2021 at 12:48 PM Jeff Scott <jeff....@nxp.com> wrote:

A couple more questions.

 

1. Is there plans for compressed variants of these instructions?

That's something we expect to study in the future.

2. Why no 0-extend byte?

The andi instruction already provides this functionality.

The GNU assembler and the llvm assembler will accept zext.b dest, src as an alias for andi dest, src, 255 in their most recent releases.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0A%2BBrhqj9m%3DHo-%2BdSeKnfjMa0XJit7qJ%3D-6TigW2Kf2pQ%40mail.gmail.com.

[Jeff Scott]

Thanks Andrew.  I figured another instruction must cover zext.b.

[Tariq Kurd]

1. Is there plans for compressed variants of these instructions?

Yes - the code-size reduction group have a proposal:

https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/Zce_spec.adoc

Tariq

[Peter Ashenden]

Looks like the RV32 encoding for the zext.h instruction clashes with that for the pack instruction (define in bitmanip-0.93) with rs2 being x0.

zext.h:

pack:

Should zext.h be an OP-IMM encoding?

Cheers,

PA

[Andrew Waterman]

Good eyes, but this is actually by design: RV32 zext.h is a subset of RV32 pack (specifically, when rs2=x0, pack performs the zext.h operation).

It's a deficiency of the current spec that this rationale is missing.  Down the road, when we've unified these specs, we'll rectify it.

--
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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0d35c909-0aef-2f1c-23e7-510448d40ffc%40astc-design.com.

[Peter Ashenden]

Thanks Andrew. Yes, I realized just before reading your reply that zext.h is just a special case of pack. Should have thought 10ns longer before posting my comment.

Cheers,

PA

[Peter Ashenden]

The single bit instructions used to be called sbset, sbclr, sbinv,
sbext. Now, the "s" is removed and they are bset, bclr, binv, and bext.
The last of these has the same name as the bit-field extract instruction
in the Zbe extension. How will this name clash be resolved?

[Craig Topper]

bext and bdep were renamed to bcompress and bdecompress in the 0.94 version of the old spec you can find on the main-history branch here https://github.com/riscv/riscv-bitmanip/blob/main-history/bitmanip-draft.pdf. I think there was a later commit to rename them to bmext and bmdep, but that never made it into the pdf.

> --
> 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 view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/16da2cc7-cd65-1d2b-47c5-73089859a023%40astc-design.com.

[Peter Ashenden]

Thanks Craig, I missed that draft.

Cheers,

PA

[David Horner]

I thought I'd already posted this. [And I mis-posted it again today]

Questions:

My question is how we justify these instructions in this format consuming substantial 32bit opcode space.

Alternate formats with destructive target register for each of the sources allows 16 time the operations in the reserved opcode space.

Most cases can be optimized by the compiler to effectively use this construct.

When a non-destructive format is preferred it can be achieved by a compressed move from the argument to the target.

This combination could be fused efficiently and be applicable to all of the extension instructions, not just these Bitmanip initial instructions.