Zmmul Public Review

[Allen Baum]

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

This extension is part of the Unprivileged Specification.

The review period begins today, January 11 and ends on Friday, February 25 (inclusive).

This extensions is described in the PDF spec available at in the draft unprivileged ISA spec here:
   https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220110-eae4f00/riscv-spec.pdf sec 9.3 page 51
which was generated from the source available in the following GitHub repo:
    https://github.com/riscv/riscv-isa-manual/blob/78696fcaacb62374d3f54678d9f4b64a4cc9de04/src/m.tex#zmmul line 171

To shortcut this, the entirety of the spec is included here:

(Spec text):

The Zmmul extension implements the multiplication subset of the M extension.
 It adds all of the instructions defined in Section 9.1, namely: MUL, MULH, MULHU, MULHSU, and (for RV64 only) MULW.
The encodings are identical to those of the corresponding M-extension instructions.

(non-normative text):

The Zmmul extension enables low-cost implementations that require multiplication operations but not division. 
For many microcontroller applications, division operations are too infrequent to justify the cost of divider hardware.
By contrast, multiplication operations are more frequent, making the cost of multiplier hardware more justifiable.
Simple FPGA soft cores particularly benefit from eliminating division but retaining multiplication,
since many FPGAs provide hard- wired multipliers but require dividers be implemented in soft logic. 

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 GitHub repo:

    https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20220110-eae4f00. 

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 tech-unprivileged 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 

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

Allen Baum

[Jiuyang Liu]

Hi, Allen,

I wonder why providing such fine granularity to RISC-V extensions?

I saw motivation is

> For many microcontroller applications, division operations are too infrequent to justify the cost of divider hardware.
> By contrast, multiplication operations are more frequent, making the cost of multiplier hardware more justifiable.
> Simple FPGA soft cores particularly benefit from eliminating division but retaining multiplication,
> since many FPGAs provide hard- wired multipliers but require dividers be implemented in soft logic. 

IMHO, I think it is traded by increasing the fragmentation to extensions, which increase the burden to IP vender and compiler engineers. I just wondering if it is really worth to add this extension or split some mini-extensions out from current extension?

Divider can have different implementations from high-end to low-end, which are different trade-offs, providing a lot of choice to architects to select.

For those who even don't wanna introduce even a single adder in some small ASIC designs, they can still use GCD algorithm while sharing ALU as adder, this won't increase the implementation difficulty or area cost (maybe only add a FSM).

For FPGA users, they also can leverage the DSP block inside FPGA(for example: https://www.xilinx.com/support/documentation/ip_documentation/div_gen/v5_1/pg151-div-gen.pdf)

So I don't think divider provides difficulty or burden to small ASIC core or FPGA implementations.

Regards,

Jiuyang Liu

[Bruce Hoult]

It's true that a simple bit-by-bit divider taking XLEN cycles is not very big, while still being much faster than a software implementation.

It is also valid for a system to implement the existing M extension by having  hardware multiplier but using trap-and-emulate for divide.

Note also that gcc (and llvm?) has long had the "-mno-div" option which causes division to use the runtime library routines even for march strings that include the M extension.

This extension is really just formalizing existing practice so that the -mno-div option can be replaced by a more honest -march option.

--
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/19eec2de-87e4-4801-ab91-67e72c6a2b5fn%40groups.riscv.org.

[Paul Donahue]

On Wednesday, January 12, 2022 at 3:18:57 AM UTC-8 Bruce Hoult wrote:

It is also valid for a system to implement the existing M extension by having  hardware multiplier but using trap-and-emulate for divide.

I disagree.  In that configuration, the AEE and SEE would support the M extension (which may be what you're talking about) but overall it would not be a valid implementation of the M extension since divides would not be transparently available to the execution environment seen by M mode (since M mode would have to provide special software).  Therefore, compliance with the M extension could not be claimed.  But Zmmul compliance could be claimed.

Thanks,

-Paul

 

[Samuel Falvo II]

M-mode illegal instruction trap handlers can still provide transparent emulation of divide instructions.  It's just that you need to remember to link that software into the M-mode binary.  Am I missing something?

--

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/4156ce5b-fd38-4050-80e2-83af24f122d9n%40groups.riscv.org.

--

Samuel A. Falvo II

[Paul Donahue]

That's true.  It's just that this isn't compliant with the architecture, which specifies the execution environment visible to M mode.  If an implementation claims to support instruction X then nobody should need to remember to link anything special and the implementation must be able to execute instruction X anywhere.  For example, in such a trap-and-emulate implementation we would not be able to execute "div x0,x0,x0" at mtvec.  Therefore, overall compliance with the M extension cannot be claimed.  The SEE and AEE can claim such support, which may be all that's needed in practice.

Thanks,

-Paul

[Allen Baum]

That's exactly right.

If you claim to support M-extension, you are effectively guaranteeing that the execution of those ops will not ever trap, and they are safe to use in any environment, including Mmode.

If a platform does require M-extension, it is relying on that guarantee.

With Zmmul, it guarantees that Mul will never trap - and still makes no guarantees that Div will trap

It could make M extension unsupported, in which case the tool chain must visibly support it (by calls or inline Mul/Div routines))

It could make M extension optional and require one of the Execution Environments to support Mul (and Div) by trapping and emulating.

It could require either M-extension or Zmmul, which guarantees that Mul execute without trapping,

    and that Div will either execute correctly, or will trap properly and that the Execution Environment will emulate it, 

It could require only Zmmul, which guarantees that Mul execute without trapping, and Div is visibly supported (by calls or inlining)

It is a platform decision.

[Samuel Falvo II]

Ahh, that makes more sense to me now.  Especially the "at mtvec" qualification.  Thank you!

[Andrew Waterman]

On Wed, Jan 12, 2022 at 12:28 AM Jiuyang Liu <l...@jiuyang.me> wrote:

Hi, Allen,

I wonder why providing such fine granularity to RISC-V extensions?

I saw motivation is

> For many microcontroller applications, division operations are too infrequent to justify the cost of divider hardware.
> By contrast, multiplication operations are more frequent, making the cost of multiplier hardware more justifiable.
> Simple FPGA soft cores particularly benefit from eliminating division but retaining multiplication,
> since many FPGAs provide hard- wired multipliers but require dividers be implemented in soft logic. 

IMHO, I think it is traded by increasing the fragmentation to extensions, which increase the burden to IP vender and compiler engineers. I just wondering if it is really worth to add this extension or split some mini-extensions out from current extension?

The fragmentation problem is real, but it should be greatly mitigated by use of profiles.  In particular, the RVA profiles (for apps processors) will mandate the M extension, and so software in this space can remain ignorant of Zmmul's existence.  The RVM profiles might(?) declare that M is supported-optional whereas Zmmul is unsupported-optional, meaning that standard library vendors shouldn't feel obligated to support Zmmul by itself.  In effect, this would restrict Zmmul's applicability to those who are willing to support their own software stacks.

--

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/19eec2de-87e4-4801-ab91-67e72c6a2b5fn%40groups.riscv.org.