Tell us about the SIMD support

[Bryght-Richard]

Will ESP32-S31 GCC support autovectorization?

Will ESP32-S31 GCC support https://gcc.gnu.org/onlinedocs/gcc/Vect ... sions.html ?

Is the SIMD instruction set more ESP32-S3 or RISCV SIMD?

[Sprite]

Not sure about autovectorization, but you can assume that given the S31 core is RiscV, the PIE will be (possibly a superset of) the PIE found in the ESP32P4.

[Bryght-Richard]

SIMD Unaligned access?

[andylinpersonal]

Some hint from the agent skills. But lacks instruction cycles of SIMD instructions and overhead of unaligned access.

[MicroController]

On the S3, and AFAIK on the P4 too, there are no unaligned memory accesses via the SIMD. Every access is always aligned, see the S3's TRM for example.

[Sprite]

I seem to remember they added unaligned SIMD access at some point, but I don't recall if it went into the P4 or the S31.

[RandomInternetGuy]

Will ESP32-S31 GCC support autovectorization?

For PIE to have been on devices like P4 and S3 now for several years, there's been little official doc about it. There was a blog post or two, and a few good posts by other random internet guy, but official doc has been slow to reach fruition and most of what's known about it seems to come from taking apart the code snippets in the DSP and DL libraries.

The P4 TRM, last time I looked, still had PIE as "0%: this section is not complete" but I see now it's been updated with enough info to safely boot the device and run binaries (e.g. not trounce the registers during a context swich or interrupt) with PIE sections. It now proudly announces that it's compliant with "Espressif’s PIE V2.2.0" but variations of that term in search lead to dead ends.

Autovectorization requires a lot of compiler chops. Since they went on their own, they can't ride the tails of Andes or other subsets of RISC-V Vector that more closely resemble SIMD-era stuff. But we can somewhat answer the question since the compilers are open source. Peek in https://github.com/espressif/gcc/blob/e ... ressif.def for RISC-V or https://github.com/espressif/gcc/blob/e ... /xtensa.cc for Xtensa (and siblings in their respective directories) and find that GCC seems to know next to nothing about the RISC-V extensions and the limit of Espressif-specific magic in XTensa is a workaround for a silicon defect in the original ESP32.

Perhaps you'll come to a different conclusion, but my study of the Xtensa and RISC-V directories in https://github.com/espressif/gcc/ as well as roaming through the crosstools-ng finds only relatively small (e.g. https://github.com/espressif/crosstool- ... d96f66c4f8) changes make over vanilla GCC. I see an enthusiastic maintainer (the last commit was 52 minutes ago. It's 05:24A in parts of North America, so it's either a fellow insomniac or someone in Asia) but I don't see evidence of autovectorization.

I could be wrong. (But I've never once seen anything but vanilla RISC-V in any of the P4 code I've disassembled.)

It seems that PIE support isn't really documented and the only customer is really the guys down the hall working on the libs with hand-coded assembly that don't even really use the assembler; they construct the opcodes in true artisan style.

Don't expect strlen to be inlined to even zero-overhead loops and certainly don't expect your operator + Vec3d[] to bowl you over.

Maybe I'm wrong. Maybe it's there. Maybe GCC 16.2 patches are in the wing.

Pretty much I have to assume that PIE does nothing for me. I don't even expect std::experimental::simd to do anything special for them.

[Sprite]

You're right in that things like autovectorization are still in the pipeline. We do have higher-level libraries like esp-dsp which abstracts the artisinally-crafted assembly into building blocks you can use in your projects.

[MicroController]

For PIE to have been on devices like P4 and S3 now for several years, there's been little official doc about it.

The S3's SIMD/PIE have been fully documented in the TRM for a couple of years now...

that don't even really use the assembler

Dunno about the artisans at Espressif, but the IDF toolchain assembles and disassembles S3 and P4 PIE instructions no problem.

The P4's PIE docs have been stuck at "81% complete" for years - and now the v3 P4 has added numerous new instructions, so I guess that 81% fell back to like 60% I'd hope the documentation efforts for the P4 are not being dropped in favor of the S31.

Pretty much I have to assume that PIE does nothing for me.

It doesn't do anything automatically. But it's also not hard to create PIE code snippets for some performance-critical sections. The P4 seems a bit limited by RAM speed, but the S3 becomes a rocket when you can use SIMD. It's a judgement call: Is a 10-20x speed-up of some specific code worth your effort to craft some assembly?