Hacker News Reader

Comment by osrec | Hacker News Reader

Genuine question: is that a good or bad thing?

It's a big plus if you want to write code for it in something like Rust. LLVM support for the architecture they used on their older chips (xtensa) for a very long time required compiling a fork of LLVM and rustc in order to target the chips. It may still, I didn't keep up with the effort to upstream that target. RISC-V is an open architecture that has a lot of people excited so compiler support for it is very good. Though as far as why Espressif is using it, it feels likely they would use it because it means they don't have to pay anyone any royalties for the ISA.

It's a mix.

Better compiler support for RISC-V, but everything I've seen from them is a much shorter pipeline than the older Xtensa cores, so flash cache misses hit it harder.

Both RISC-V and Xtensa suffer from the lack of an ALU carry bit for the purposes of improving pipelining. But for these small cores it means 64-bit integer math usually takes a few more cycles than a Cortex-M Arm chip

But that also depends on what you use it for. If you're after the wifi and IO and other nice things for a mostly idle device - the pipeline is almost irrelevant. Esphome can run on older versions just fine too. On the other hand if you're doing something very optimised and need tight timing around interrupts to drive external hardware - it may matter a lot.

So... depends on the project.

Absolutely correct.

The Xtensa variants also come with dual core options, which means you can offload timing sensitive stuff to a dedicated core.

My playing with C3 betrayed that you have to use much larger buffers for things like i2s to make it work without glitching.

I also found splitting interrupts between the two cores helps with latency, but even if one core has only a single interrupt, that interrupt latency is increased compared to a single core system with a single interrupt. I suspect this is at least partly because they only put a single fetch pipe between the instruction cache and the crossbar.

I think it would be hard to argue that an ALU carry bit was a good idea, even if 64-bit maths takes a few more cycles.

There's definitely a trade-off between things that seem relatively simple to ISA but can really complicate the pipeline.

Xtensa pays for it with crippled 64-bit performance, which has a lot of downstream impacts. Ex: division by a constant is also slower. Most compilers don't even bother fast pathing 64-bit division by a constant.

I was surprised to find Apple kept ADC/ADCS in aarch64. Maybe this ends up being one of those things that's less useful or potentially a bottleneck depending on the specific implementation. Edit: backwards compatibility probably.

The fact that a few cores have bolted it on to RISC-V makes me think I must not be alone in missing it.

Unless you're a shareholder of arm, hard to see how it's a bad thing.

The other core they've used is Xtensa

Reply on news.ycombinator.com