7 ms·

4 new specs 1. UEFI 2. Supervisor Binary Interface 3. Efficient Trace/Debug 4. Zmul only. This is the one that confused me. > “For many microcontroller ap

4 new specs 1. UEFI 2. Supervisor Binary Interface 3. Efficient Trace/Debug 4. Zmul only. This is the one that confused me. > “For many microcontroller applications, division operations are too infrequent to justify the cost of divider hardware,” explained Himelstein. “The RISC-V Zmmul extension will benefit simple FPGA soft cores in particular.” This doesn't look like bloat to me. But I have no experience in RISC V.

brucehoult 4y ago
It's always been legal to say you implement the M extension, but only actually implement multiply in hardware, and provide a trap and emulate solution for the division instructions. There has long been a -mno-div flag for gcc and clang to tell them not to generate divide instructions (i.e. call a library divide function directly, to save trap overhead) even though the M extension is present. This just provides a way to express that commonly-used functionality via an ISA string instead.
- pclmulqdq 4y ago
  Yes, except that's one more trap handler to implement. And it's a lot slower than inlining the division code when you need it.
  - prettyStandard 4y ago
    Yes but this is better than not implementing the trap.
    - pclmulqdq 4y ago
      Wait, having no DIV instruction will result in faster code than having a DIV that traps. The compiler picks up the code that happens in the trap and can optimize it. For example, the code for an 8-bit division can be a lot faster than a 32-bit DIV on a microcontroller.
      - Someone 4y ago
        There’s also the overhead of trapping (registers get saved, the CPU may switch to kernel mode). For a single integer division, chances are that adds significant overhead compared to a subroutine call (let alone inlined code)
  - avianes 4y ago
    DIV that traps is for binary compatibility, not performance.
- prettyStandard 4y ago
  Yes but that does seem to be better than not standardizing it as an architecture, but you can always fall back on the trap in the absence of being able to link with binaries from the preferred Zmul only architecture.
  - kragen 4y ago
    You're thinking of cellphones and workstations, but Zmul is about microcontrollers, not workstations. The temperature controller in your Pinecil soldering iron might not implement division or have a trap mechanism at all, nor enough Flash to waste some on unused division trap handlers, and there's no point in trying to link a precompiled copy of OpenSSL into its firmware anyway. Nevertheless, if it's RISC-V, you can compile its firmware with GCC or clang. And hardware multiplication is super useful for real-time control systems with, for example, PID controllers in them. https://www.pine64.org/pinecil/ https://www.pine64.org/pinecil/
    - foobarian 4y ago
      Wow. Why does a soldering iron need an OS? And a 32 bit processor? What kind of timeline is this :-(
      - kragen 4y ago
        Of course you don't need an OS and a 32-bit computer in your soldering iron, but they are nice. An OS is nice because you can have multiple real-time tasks with different priority levels, so that you can, for example, update the screen without worrying that it will screw up the PID control loop maintaining the iron's temperature. You don't need a screen, but a screen is nice because you can see what temperature the iron is set to and what temperature it's measuring. This makes it easier to set the temperature. Also IronOS lets you set the cutoff voltage so you don't kill your batteries by draining them down to zero, and it has an option to correct inaccurate temperature readings from the tip by calibrating the tip. PID temperature control is nice, not only because the iron is ready for use much more quickly, consumes much less energy (making battery power practical), and weighs less, but also because it allows you to solder things to big copper pours without overheating your iron all the time, which means you burn components and lift traces a lot less often. This is especially nice if a heat-damaged component might not fail until after the circuit board is on orbit, which makes it impractical to replace, or until it's in use in a life-critical application, which makes replacement the least of your worries. But you don't need it. A 32-bit processor is nice because it means you can use 32-bit math for everything instead of constantly worrying about overflow. Also, you can address the entire 128 KiB of Flash without shitty memory segmentation headaches when you're writing the firmware. 128 KiB of Flash is nice because it's easy for even a single person to write more than 64 KiB of code, even with RV32C's superior code compactness and without using libraries — though, to be fair, an alternative way to get 128 KiB or 256 KiB of code space is to make your code space word-addressed instead of byte-addressed, and then make your instructions 16 bits or 32 bits long. Generally this requires a Harvard architecture, which is common in microcontrollers but not ideal. None of these nice things requires or even benefits from a division instruction (though in practice they probably do need interrupt handling and illegal-instruction traps, which could be used to emulate division if it were really necessary). So I always thought it was kind of goofy that the M multiply-instruction extension, crucial to DSP work, was saddled with this white elephant of hardware division support. I'm glad to see that's fixed as far as it can be with Zmmul. The GD32VF103 used in the Pinecil doesn't have memory protection, so IronOS https://github.com/Ralim/IronOS https://github.com/Ralim/IronOS might not be the kind of operating system you're thinking it is. It doesn't have, for example, a filesystem, a command prompt, a GUI, a task list UI, or a networking stack. I don't even think tasks are created and destroyed at runtime; all the running tasks are compiled into the OS image. Having an OS and a 32-bit microcontroller in your soldering iron might be a terrible idea: for example, it could include malware that displays advertisements or disables your soldering iron if you haven't paid your monthly subscription. The Pinecil solves this problem by being 100% free software, so that even if the IronOS maintainers try to pull something like that, you have the freedom to fork their code and remove the malware. You still have the problems that the iron can have more complicated malfunctions and is harder to repair than an iron that is just a resistor that plugs into the wall. But I think the advantages of tighter control more than make up for that. But if you really need to, you can solder your circuits by heating up a chunk of brass in the flame of your gas stove, then pressing it to the circuit board before it cools off. I've done it. But I'd rather not.
555dreams 4y ago
Despite sounding weird, the multiplication without division is actually very helpful for low cost and resource constrained MCUs/soft-CPUs. Even utilizing the `mno-div` complication flag, division can still occur in precompiled binaries that are linked (because the linker looks at the -march setting). By standardizing the use of multiplication without division we can avoid dealing with this. As a side note, I ran into this exact problem in a work project last year and needed to implement software division in an illegal instruction handler to get around it.
- CoastalCoder 4y ago
  > `mno-div` complication flag Brilliantly put.
zdw 4y ago
The DEC Alpha line of processors famously lack integer division: > There is no instruction(s) for division as the architects considered the implementation of division in hardware to be adverse to simplicity. https://en.wikipedia.org/wiki/DEC_Alpha#Integer_arithmetic https://en.wikipedia.org/wiki/DEC_Alpha#Integer_arithmetic
- mmoskal 4y ago
  Interestingly, ARM11 used in original RPi and RPi Zero also doesn't have integer division, but it has floating point division.
  - KerrAvon 4y ago
    Divide being missing is not totally uncommon in CPU architecture. If I'm not mistaken, the Cray-1 didn't have a divide instruction either, just reciprocal approximation.
    - monocasa 4y ago
      SH4 (and SH2 I think?) was an interesting mid point, which architecturally exposed the single cycle ops that would back an iterative divide, letting you pick the precision you wanted.
crest 4y ago
Are there really (enough) RISC V cores having no microcode sequencer at all and would have to add one just to implement a 1 bit per cycle microcoded divide instruction?
- bpye 4y ago
  I can’t think of many RISC-V cores that are microcode sequenced. There are some toy implementations using ucode - but I can’t think of any that have seen serious use. Maybe you’d count SERV?
  - monocasa 4y ago
    If you take a step back and define the concept in question as 'cores that have pipeline stages that can block the pipeline as they work their way through a core local state machine (whether that state machine is encoded in a table form via microcode or via a sea of logic)', then there's quite a few on the low end for multiply support. Remember that RV32EM is competing with Cortex-M0, which can get down to 12k gates when it has an iterative, bit-serial multiply.
    - bpye 4y ago
      Whilst true for multiply, divide is considerably more complex. You have to step up to the M3 to get a divide instruction on the ARM side. This is why the new Zmmul is valuable over the existing M extension.
      - monocasa 4y ago
        Agreed, but the point was that state machine, iterative, blocking pipeline stages are pretty common even in RISC cores, including particularly ascetic RISC-V and ARM cores. But I can get how at ~12k gates you don't even want the slowest iterative divide unit.
- deleted 4y ago
  [deleted]

brucehoult 4y ago

It's always been legal to say you implement the M extension, but only actually implement multiply in hardware, and provide a trap and emulate solution for the division instructions. There has long been a -mno-div flag for gcc and clang to tell them not to generate divide instructions (i.e. call a library divide function directly, to save trap overhead) even though the M extension is present. This just provides a way to express that commonly-used functionality via an ISA string instead.

pclmulqdq 4y ago
Yes, except that's one more trap handler to implement. And it's a lot slower than inlining the division code when you need it.
- prettyStandard 4y ago
  Yes but this is better than not implementing the trap.
  - pclmulqdq 4y ago
    Wait, having no DIV instruction will result in faster code than having a DIV that traps. The compiler picks up the code that happens in the trap and can optimize it. For example, the code for an 8-bit division can be a lot faster than a 32-bit DIV on a microcontroller.
    - Someone 4y ago
      There’s also the overhead of trapping (registers get saved, the CPU may switch to kernel mode). For a single integer division, chances are that adds significant overhead compared to a subroutine call (let alone inlined code)
- avianes 4y ago
  DIV that traps is for binary compatibility, not performance.
prettyStandard 4y ago
Yes but that does seem to be better than not standardizing it as an architecture, but you can always fall back on the trap in the absence of being able to link with binaries from the preferred Zmul only architecture.
- kragen 4y ago
  You're thinking of cellphones and workstations, but Zmul is about microcontrollers, not workstations. The temperature controller in your Pinecil soldering iron might not implement division or have a trap mechanism at all, nor enough Flash to waste some on unused division trap handlers, and there's no point in trying to link a precompiled copy of OpenSSL into its firmware anyway. Nevertheless, if it's RISC-V, you can compile its firmware with GCC or clang. And hardware multiplication is super useful for real-time control systems with, for example, PID controllers in them. https://www.pine64.org/pinecil/ https://www.pine64.org/pinecil/
  - foobarian 4y ago
    Wow. Why does a soldering iron need an OS? And a 32 bit processor? What kind of timeline is this :-(
    - kragen 4y ago
      Of course you don't need an OS and a 32-bit computer in your soldering iron, but they are nice. An OS is nice because you can have multiple real-time tasks with different priority levels, so that you can, for example, update the screen without worrying that it will screw up the PID control loop maintaining the iron's temperature. You don't need a screen, but a screen is nice because you can see what temperature the iron is set to and what temperature it's measuring. This makes it easier to set the temperature. Also IronOS lets you set the cutoff voltage so you don't kill your batteries by draining them down to zero, and it has an option to correct inaccurate temperature readings from the tip by calibrating the tip. PID temperature control is nice, not only because the iron is ready for use much more quickly, consumes much less energy (making battery power practical), and weighs less, but also because it allows you to solder things to big copper pours without overheating your iron all the time, which means you burn components and lift traces a lot less often. This is especially nice if a heat-damaged component might not fail until after the circuit board is on orbit, which makes it impractical to replace, or until it's in use in a life-critical application, which makes replacement the least of your worries. But you don't need it. A 32-bit processor is nice because it means you can use 32-bit math for everything instead of constantly worrying about overflow. Also, you can address the entire 128 KiB of Flash without shitty memory segmentation headaches when you're writing the firmware. 128 KiB of Flash is nice because it's easy for even a single person to write more than 64 KiB of code, even with RV32C's superior code compactness and without using libraries — though, to be fair, an alternative way to get 128 KiB or 256 KiB of code space is to make your code space word-addressed instead of byte-addressed, and then make your instructions 16 bits or 32 bits long. Generally this requires a Harvard architecture, which is common in microcontrollers but not ideal. None of these nice things requires or even benefits from a division instruction (though in practice they probably do need interrupt handling and illegal-instruction traps, which could be used to emulate division if it were really necessary). So I always thought it was kind of goofy that the M multiply-instruction extension, crucial to DSP work, was saddled with this white elephant of hardware division support. I'm glad to see that's fixed as far as it can be with Zmmul. The GD32VF103 used in the Pinecil doesn't have memory protection, so IronOS https://github.com/Ralim/IronOS https://github.com/Ralim/IronOS might not be the kind of operating system you're thinking it is. It doesn't have, for example, a filesystem, a command prompt, a GUI, a task list UI, or a networking stack. I don't even think tasks are created and destroyed at runtime; all the running tasks are compiled into the OS image. Having an OS and a 32-bit microcontroller in your soldering iron might be a terrible idea: for example, it could include malware that displays advertisements or disables your soldering iron if you haven't paid your monthly subscription. The Pinecil solves this problem by being 100% free software, so that even if the IronOS maintainers try to pull something like that, you have the freedom to fork their code and remove the malware. You still have the problems that the iron can have more complicated malfunctions and is harder to repair than an iron that is just a resistor that plugs into the wall. But I think the advantages of tighter control more than make up for that. But if you really need to, you can solder your circuits by heating up a chunk of brass in the flame of your gas stove, then pressing it to the circuit board before it cools off. I've done it. But I'd rather not.

555dreams 4y ago

Despite sounding weird, the multiplication without division is actually very helpful for low cost and resource constrained MCUs/soft-CPUs. Even utilizing the `mno-div` complication flag, division can still occur in precompiled binaries that are linked (because the linker looks at the -march setting). By standardizing the use of multiplication without division we can avoid dealing with this. As a side note, I ran into this exact problem in a work project last year and needed to implement software division in an illegal instruction handler to get around it.

CoastalCoder 4y ago
> `mno-div` complication flag Brilliantly put.

zdw 4y ago

The DEC Alpha line of processors famously lack integer division: > There is no instruction(s) for division as the architects considered the implementation of division in hardware to be adverse to simplicity. https://en.wikipedia.org/wiki/DEC_Alpha#Integer_arithmetic https://en.wikipedia.org/wiki/DEC_Alpha#Integer_arithmetic

mmoskal 4y ago
Interestingly, ARM11 used in original RPi and RPi Zero also doesn't have integer division, but it has floating point division.
- KerrAvon 4y ago
  Divide being missing is not totally uncommon in CPU architecture. If I'm not mistaken, the Cray-1 didn't have a divide instruction either, just reciprocal approximation.
  - monocasa 4y ago
    SH4 (and SH2 I think?) was an interesting mid point, which architecturally exposed the single cycle ops that would back an iterative divide, letting you pick the precision you wanted.

crest 4y ago

Are there really (enough) RISC V cores having no microcode sequencer at all and would have to add one just to implement a 1 bit per cycle microcoded divide instruction?

bpye 4y ago
I can’t think of many RISC-V cores that are microcode sequenced. There are some toy implementations using ucode - but I can’t think of any that have seen serious use. Maybe you’d count SERV?
- monocasa 4y ago
  If you take a step back and define the concept in question as 'cores that have pipeline stages that can block the pipeline as they work their way through a core local state machine (whether that state machine is encoded in a table form via microcode or via a sea of logic)', then there's quite a few on the low end for multiply support. Remember that RV32EM is competing with Cortex-M0, which can get down to 12k gates when it has an iterative, bit-serial multiply.
  - bpye 4y ago
    Whilst true for multiply, divide is considerably more complex. You have to step up to the M3 to get a divide instruction on the ARM side. This is why the new Zmmul is valuable over the existing M extension.
    - monocasa 4y ago
      Agreed, but the point was that state machine, iterative, blocking pipeline stages are pretty common even in RISC cores, including particularly ascetic RISC-V and ARM cores. But I can get how at ~12k gates you don't even want the slowest iterative divide unit.
deleted 4y ago
[deleted]