Announcement

Collapse
No announcement yet.

RISC-V Announces Initial Batch Of 2022 Specifications: SBI, UEFI, Zmmul, E-Trace

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RISC-V Announces Initial Batch Of 2022 Specifications: SBI, UEFI, Zmmul, E-Trace

    Phoronix: RISC-V Announces Initial Batch Of 2022 Specifications: SBI, UEFI, Zmmul, E-Trace

    RISC-V International announced their first batch of new specifications for 2022. This includes approving of Efficient Trace for RISC-V (E-Trace), RISC-V Supervisor Binary Interface (SBI), RISC-V UEFI, and RISC-V Zmmul multiply-only extensions...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Maybe RISC-V UEFI can be used together with TianoCore EDK II?
    Documentation and status of UEFI on RISC-V. Contribute to riscv-admin/riscv-uefi-edk2-docs development by creating an account on GitHub.

    Comment


    • #3
      So how many existing implementations *aren't* conformant?

      Comment


      • #4
        I know this is slightly off-topic, but regarding Zmmul my thought is: not this shit again, I thought we are finally past the times of missing or shitty hardware division (non-ancient ARM (even 32-bit, IIRC starting with v7) now has it as well, and Intel fixed their divider with Ice Lake). I really like the idea of an open-source, versatile, RISC instruction set, but I think RISC-V is hiding too much basic functionality behind extensions and introducing too much fragmentation. Zmmul is not the first here, M being an extension in the first place is not a great idea I think, and A and Zifencei are just ridiculous.

        Comment


        • #5
          Originally posted by archkde View Post
          I know this is slightly off-topic, but regarding Zmmul my thought is: not this shit again, I thought we are finally past the times of missing or shitty hardware division (non-ancient ARM (even 32-bit, IIRC starting with v7) now has it as well, and Intel fixed their divider with Ice Lake). I really like the idea of an open-source, versatile, RISC instruction set, but I think RISC-V is hiding too much basic functionality behind extensions and introducing too much fragmentation. Zmmul is not the first here, M being an extension in the first place is not a great idea I think, and A and Zifencei are just ridiculous.
          I mostly agree with you on RV in terms of fragmentation, but I have to wonder... what kind of code are you running where division performance is critical? The analysis I've seen of most codes is that most idiv is by a constant and can be implemented efficiently as shift-sub.

          Comment


          • #6
            Originally posted by Dawn View Post

            I mostly agree with you on RV in terms of fragmentation, but I have to wonder... what kind of code are you running where division performance is critical? The analysis I've seen of most codes is that most idiv is by a constant and can be implemented efficiently as shift-sub.
            Division performance is not critical to me, but I don't like that a large amount of effort has had to be spent on software workarounds (compiler optimization passes, libdivide) to work around Intel's shitty microcode loop for integer division, when they already have rather capable dividers on-chip anyway (for floating point).

            Comment


            • #7
              Originally posted by archkde View Post

              Division performance is not critical to me, but I don't like that a large amount of effort has had to be spent on software workarounds (compiler optimization passes, libdivide) to work around Intel's shitty microcode loop for integer division, when they already have rather capable dividers on-chip anyway (for floating point).
              Application ISA profile (i.e. the profile for the sort of implementation that can run Linux) won't stop requiring M, which includes division.

              This new extension is for simpler microcontrollers which do not implement application profile. They might be RV32IMA today, they'll be RV32IA + Zmmul, in the future.

              Comment


              • #8
                Originally posted by Developer12 View Post
                So how many existing implementations *aren't* conformant?
                So far there is the Allwinner D1 which has a vector engine that is based on a early non release state of the V spec and is not compatible with the final spec. That is about all. So far there are about 4 RISCV SoCs that normal people have even seen, the two SoC's from SiFive, the StarFive Dual Core and the Allwinner D1.

                Comment


                • #9
                  Originally posted by Alexmitter View Post

                  So far there is the Allwinner D1 which has a vector engine that is based on a early non release state of the V spec and is not compatible with the final spec. That is about all. So far there are about 4 RISCV SoCs that normal people have even seen, the two SoC's from SiFive, the StarFive Dual Core and the Allwinner D1.
                  I don't just mean nonconformant in the sense that they implement the spec but it doesn't match. I'm also referring to all existing SoCs that don't implement at all some or all of these specifications.

                  Comment


                  • #10
                    Originally posted by archkde View Post
                    regarding Zmmul my thought is: not this shit again, I thought we are finally past the times of missing or shitty hardware division
                    People will always be trying to push programmable hardware into smaller, cheaper, and lower-power applications, where a hard-wired integer divider is not a negligible cost.

                    Originally posted by archkde View Post
                    Intel fixed their divider with Ice Lake
                    There are still a great many chips fabbed at far bigger process nodes, like 180 nm.

                    Originally posted by Dawn View Post
                    I have to wonder... what kind of code are you running where division performance is critical? The analysis I've seen of most codes is that most idiv is by a constant
                    For sure, I do. I even remember practically salivating, while reading about then-upcoming Core 2's optimizations of integer division (which was coincidentally not long after I learned just how dismal it was on the Pentium 4).

                    I'm trying to remember what I was using it for, at the time... perhaps a simple Hough transform.
                    Last edited by coder; 22 June 2022, 03:22 PM.

                    Comment

                    Working...
                    X