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.
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.
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.
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.
Wow. Why does a soldering iron need an OS? And a 32 bit processor? What kind of timeline is this :-(
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 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.