Comment by brucehoult | Hacker News Reader

Comment by brucehoult | Hacker News Reader

Parent Full thread

> milk-v duo ... no wifi tho

Look no further than the BL808, a rather similar chip that has WIFI/BT. Available in the Sipeed M1s Module and Pine64 Ox64. It also has a 64 bit core that runs Linux (and 64 MB in-package RAM), and two smaller cores, the smallest dedicated to running the WIFI/BT.

Or the BL602/BL604, which are more like the ESP32. Off the shelf boards include the Pine64 PineCone and Sipeed BL602 EVB. Lup Yuen Lee has written extensively about how to run Apache NuttX RTOS on these.

All the above are RISC-V.

> risc-v or especially arm is a much nicer way

I agree on the "Arm" but not the "especially".

First off, do you mean ARM7TDMI, ARMv6 (original Pi and Zero), ARMv6-M (Cortex-M0 e.g. Pi Pico), ARMv7-M (Cortex-M3), ARMv7-A (early Pi 2), ARMv8-A (Pi 3 and later)? There are significant differences between all of them. The first two support similar versions of both the original ARM ISA and also Thumb1. The Pi Pico supports Thumb1 with a couple of added CSR instructions (only). Pi 2 supports Thumb2 and original ISA. Pi 3 and later support the 64 bit ISA, and also the standard and Thumb2 32 bit ISAs.

I'd recommend beginners to learn either original fixed length 32 bit opcode ARMv6 (or earlier), or else Thumb1. Both have their good points, but also bad. Individual instructions in A32 are quite complex to understand, between predication, condition codes, "free" shifts, and it has quite a lot of different instruction formats. Thumb1 has much simpler instructions, similar to other ISAs, but has a quite restricted set of instructions, it's fiddly to use registers 8-12, and it had even more different instruction formats.

Thumb2 is just a huge complex mess. Arm64 is also hugely complex.

In comparison RISC-V is simplicity itself, with only four basic instruction formats in RV32I/RV64I and about half as many instructions as even Thumb1, yet it allows you to efficiently do anything. You can use RVC's shorter opcodes or not, as you wish. The register set is totally uniform (except x0). Moving between 32 bit and 64 bit doesn't require learning a different ISA, just a different register size.

But for sure the Arm mess is better than the x86 mess.

a note about the ox64, i just mentioned it on #riscv and someone replied

> the ox64 look nice but have issue. in 1 week at class we killed 22. I personaly killed 5. they are very touchy. no [not static] we would flash the project code . it would start to boot and then fail. and when you tried to reflash them they became unresponsive

so maybe there are some problems to work out with the ox64, or maybe they were doing something wrong in the class despite wearing antistatic ankle bracelets. pine64 has been very good and trustworthy in the past so if the problem is real i'm sure they'll figure out some way to solve the problem; hopefully it doesn't involve withdrawing the ox64

nice to hear about the bl808; looks like the ox64 is also 8 dollars

by 'arm' i mean armv3 (such as arm700) without thumb, with only 33 instructions; armv6 and armv7 are almost perfectly backwards compatible, perfectly unless you're doing something really weird. i definitely don't mean aarch64. thumb is very nice if you're size-optimizing your code, but it adds a lot of headaches (though there are some improvements too). we're talking about introducing computer science students to assembly language, which admittedly i don't have much experience doing. but, my guess from the little experience i do have is that for that purpose anything that makes it easier to understand the mapping from your intention to an actual runnable instruction is going to be helpful

and arm has a number of features that make high-performance implementations more difficult but make it easier to write assembly: ldm/stm, preincrement and postincrement addressing modes, a two-register addressing mode, bit-shifted operands, bit-shifted indices, and conditional execution. even the instruction format is surprisingly readable; you can just about read a hex dump digit by digit. for the most part everything is delightfully boring, just getting out of your way. the only real dark spots i've found from this point of view are loading constants, the small register set, the lack of a division instruction, interrupt handling (fixed in cortex at the expense of speed), and thumb

risc-v is pretty simple, and dramatically superior if you're teaching computer engineering and building a cpu rather than computer science and writing assembly programs. it's even more delightfully boring than arm. it omits all the features of arm i listed above that make high-performance implementations so difficult, and, just as you say, has fewer instruction formats (in part because it isn't wasting bits on conditionalization). rv32i has 40 instructions, more than armv3 but only slightly, and the larger register set is more comfortable. rvc is brilliant, totally avoiding the hassles of thumb (core dumps when the t bit is wrong, more painful disassembly, and the arbitrary-seeming restrictions on what you're allowed to do) while actually slightly beating it at density. and rv64c exists, while aarch64 thumb doesn't

but, because of the missing but problematic conveniences of arm, my risc-v assembly always comes out to be a lot longer than my arm assembly, and that makes it harder to read. it's also much harder to read in a hex dump, to the point that i don't bother trying, because the instruction formats are carefully optimized for hardware, which is probably what you want in an instruction set you're going to implement and use. the m extension, bundling division with multiplication, is poorly thought out for actual hardware but well thought out for introductory classes; including a division instruction is helpful for learners but adds punishing complexity to low-end hardware in exchange for little performance gain. i forget the name of the new multiplication-only extension that fixes this

speaking of extensions, the main selling point of risc-v is that you can extend it however you like, so people do, and the result is an enormous diversity of instruction sets, more even than for arm. for the most part you can just ignore this unless you're writing an operating system tho

risc-v is probably going to eat arm's lunch rather quickly in the microcontroller world, but it's probably going to be decades before you can't buy a new stm32f104 or similar arm chip. both risc-v and arm make it possible to run the same architecture on your workstation and your microcontroller, which is a nice reduction in the unnecessary complexity of the whole system, but for the time being it's a lot more practical to run linux on an arm than on a risc-v, something which will hopefully change this year.

the hottest microcontrollers out there from my point of view are the esp32-c3, the stm32 family, the ch32v003, the apollo3, and the pms150c, which is its own weird 8-bit architecture; the others are evenly divided between arm and risc-v. there isn't an x86 even in the running and hasn't been for decades

Not much to disagree with there. ARMv3 is not bad. They'd got the flags out of the PC. A bit annoying to have only (IIRC) the "Single Data Transfer" format for load/store of words or zero-extended bytes. No halfword, and no sign-extended byte. That's pretty much the instruction count difference to RV32I right there, as that has uniform W, H, HU, B, BU handling -- and with the same choice of offsets in all cases, unlike ARM. I might prefer ARMv4 because of that e.g. ARM7TDMI, but ignoring Thumb. But it does add instruction encoding complexity.

Reading hex dumps -- it's never going to be easy to make hand readable/writable instruction formats in hex when you have 5 bit register fields. I've sometimes thought about doing a hex-friendly RV32E custom encoding.

PUSH/POP multiple is handy for function entry/exit, but the A32 asm syntax for it isn't very friendly. Thumb is better in that regard. RISC-V lets you write functions that set up the stack frame and save ra and s0-sN by using an alternative return address register (traditionally x5), and similarly functions to restore the registers and return. GCC even comes with these functions (total 96 bytes of code last time I looked) and uses them if you give the -msave-restore option. That cuts down function length a lot.

oh hey, i didn't know gcc shipped with the save-restore millicode and an option to use it, that's cool!

with .syntax unified you have a fairly friendly push/pop multiple syntax, whether you're using thumb or not

agreed about the instruction encoding complexity over rv32i and about halfwords and signed bytes. the arm7 datasheet includes example sequences for, among other things, loading halfwords, division, and an lfsr, but that kind of detour is exactly the kind of thing that adds potentially unintentional difficulty to classwork

rv32i also has more instructions than armv3 because it has shift instructions, while armv3 has optional shifts or rotates in most instructions, which certainly isn't a reduction in complexity with respect to risc-v

maybe you could make a base32 word dumper using 0123456789abcdefghijklmnopqrstuv? won't help much with the standard risc-v instruction encoding... and once you're swizzling split immediate fields around, you might as well write a disassembler

an octal-friendly rv32c custom encoding might be more achievable. this is vaguely related to graham smecher's "minimax" implementation of risc-v, where the hardware only implements the two-operand compressed instruction set plus a few extra instructions, and uncompressed instructions trap to microcode. or millicode, i guess

Reply on news.ycombinator.com