Xtensa Support

[schroffl]

Hi guys,

is it currently possible to compile Zig for the ESP8266/ESP32? According to this forum post it seems like LLVM supports it as a target. I would love to help with this feat, but I'm not really sure where to start. The most helpful thing I could find is this fork.

If someone could provide me a little kickstart from which I can dive into this matter I would be very thankful :)

[frett27]

Currently zig is compiled against LLVM10 that is not yet supported for extensa. Compiling extensa extension against LLVM10 is not straight forward yet as it is not in the main stream.
You have a boostrap for compiling zig, with llvm here, it might help if you want to have a deep dive on it : https://github.com/ziglang/zig-bootstrap

[schroffl]

So I have to install an LLVM-Version with extensa-support and then build zig with that?

[pixelherodev]

Yes, exactly.

[pixelherodev]

Actually, there's more work you would need to get XTensa even to what we would consider a tier IV target: you'd probably need to teach Zig's stage1 compiler how to tell LLVM to target XTensa.

[schroffl]

I noticed that I accidentally entered an invalid URL for the forum post. If any of you want to have a look – it's fixed now.

[frett27]

Seems expressif is near to release the expressif llvm10 , so it will be compatible (with the pixeldev modifications to do on architecture declaration in zig) espressif/llvm-project#18

[creationix]

I see this is now part of the 0.8.0 milestone, but that's not due for release till next summer. Looking upstream at the expresif repo it appears they have merged in the bits. Would it be possible for me to build their llvm from source and then bootstrap zig using that or are there still major parts missing?

[daurnimator]

Looking upstream at the expresif repo it appears they have merged in the bits.

Indeed it looks like just 7 days ago they published their LLVM 11 branch (hooray!) espressif/llvm-project#42

For zig itself to rely on it, we would it to be merged into upstream LLVM. However:

Would it be possible for me to build their llvm from source and then bootstrap zig using that or are there still major parts missing?

you could definitely start work now on zig support for xtensa on top of their LLVM fork.

[FireFox317]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

[daurnimator]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

I believe that is true. To start with you can get zig build-obj working though. I believe a few people have made progress here before

• @inetbowser ?
• https://github.com/Schroedingers-Hat/xtensa-zig
• @SuperAuguste ?

[creationix]

Thanks. I'm afraid this is still a bit too involved than I'm able to work with at the moment. I'm glad it's getting closer though!

I'm really excited for the day I can write esp32 firmware using zig.

[inetbowser]

Hi,
Sry for the late response, didn't see I was mentioned here :D
I managed to get Zig working for ESP32/ESP8266. Though the Xtensa backend still has some minor problems (see here).

[pyrossh]

Nice will see if I can get some zig code to display something on my m5stack core.

[frett27]

awesome !

[kassane]

Hi,
Sry for the late response, didn't see I was mentioned here :D
I managed to get Zig working for ESP32/ESP8266. Though the Xtensa backend still has some minor problems (see here).

I try compile on my machine, and made some readjustments in the build file of the zig-bootstrap repo especially for this project, but after compiling everything right at the end this problem occurs and I didn't know that still had this additional parameter.
run: build x86_64-linux-musl

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LLVM_LLVMXTENSAUTILS_LIB
    linked by target "zigcpp" in directory /home/kassane/Downloads/Code/xtensa-bootstrap/zig

status

llvm-host build: 🆗
zig-host build: 🆗
llvm-musl build: 🆗
zig-musl build: ❌

---

Tests (zig-host)

So today when I tried some tests with zig-host and couldn't generate the object file due to the lld error, but after adding the parameter -fno-LLVM then the object is generated, however xtensa-esp32-elf-gcc doesn't recognize the file structure.

Note: both tests are simple main function!

$> zig build-obj test.zig -target xtensa-freestanding -mcpu esp32 # error
...
$> zig build-obj test.zig -target xtensa-freestanding -mcpu esp32 -fno-LLVM # object generated
...
$> xtensa-esp32-elf-gcc test.o --verbose

Output:

Using built-in specs.
COLLECT_GCC=xtensa-esp32-elf-gcc
COLLECT_LTO_WRAPPER=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/lto-wrapper
Target: xtensa-esp32-elf
Configured with: /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf --prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf --exec_prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf --with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf --with-headers=/builds/idf/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.24.0.302_32e30a1' --disable-__cxa_atexit --enable-cxx-flags=-ffunction-sections --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpfr=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-mpc=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --with-isl=/builds/idf/crosstool-NG/.build/xtensa-esp32-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-nls --enable-multiarch --enable-languages=c,c++ --disable-libstdcxx-verbose --enable-threads=posix --enable-gcov-custom-rtio --enable-libstdcxx-time=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (crosstool-NG 1.24.0.302_32e30a1) 
COMPILER_PATH=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/:/home/kassane/.local/bin/../libexec/gcc/:/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/
LIBRARY_PATH=/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/:/home/kassane/.local/bin/../lib/gcc/:/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/
COLLECT_GCC_OPTIONS='-v'
 /home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/collect2 -plugin /home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/liblto_plugin.so -plugin-opt=/home/kassane/.local/bin/../libexec/gcc/xtensa-esp32-elf/10.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc847BiG.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lnosys -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/crt0.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crti.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtbegin.o -L/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0 -L/home/kassane/.local/bin/../lib/gcc -L/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib test.o -lgcc -lc -lnosys -lc -lgcc /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtend.o /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/crtn.o
/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/lib/crt0.o:(.literal+0x0): undefined reference to `main'
/home/kassane/.local/bin/../lib/gcc/xtensa-esp32-elf/10.2.0/../../../../xtensa-esp32-elf/bin/ld: final link failed: file truncated
collect2: error: ld returned 1 exit status

zig cc

$> zig cc -c test.c -target xtensa-freestanding -mcpu esp32 # crash compiler
...
$> zig cc -emit-llvm test.c -target xtensa-freestanding -mcpu esp32 # linker error
# output:
ld.lld: error: /home/kassane/.cache/zig/o/a3ec2f7e1c524519e2519734f1740cc5/test.o: could not infer e_machine from bitcode target triple xtensa-unknown-unknown-eabi

[inetbowser]

@kassane did you already try to build zig with these steps? With the zig built with these steps everything works like expected.

[kassane]

@inetbowser, yep

I used all the parameters to compile the LLVM (-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="Xtensa").
I used the Bootstrap build file as a reference, but following xtensa.md step by step.

[weitzj]

Do you have a goal in mind how this relates to the free standing compiler without LLVM?

[kassane]

More alternative:
https://github.com/ominitay/zig/tree/xtensa

@ominitay, what is the difference of this proposal compared to others?

[ominitay]

Ooooop I didn't spot this
Hopefully nothing??

[ominitay]

So running a git diff, there are a couple slight things missing from theirs that are included in mine, but they should be functionally the same.

[jaedson-barbosa]

Any news on this?

[weitzjdevk]

Llvm 16 got released https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.0

[kassane]

@weitzj ,
Try following the LLVM16 branch:
0ca3582

[jaedson-barbosa]

Hi, is there any way for me to collaborate on this support addition?
Is there an issue logging everything that still needs to be done?

[andrewrk]

Zig master branch now depends on LLVM 16, which has experimental Xtensa support. This means it is disabled by default. In order to play with Xtensa and Zig together, you need to build LLVM from source using -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Xtensa and build Zig with -Dllvm_has_xtensa.

[kassane]

This means it is disabled by default. In order to play with Xtensa and Zig together, you need to build LLVM from source using -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Xtensa and build Zig with -Dllvm_has_xtensa.

Missing add on build.zig llvm_libs:

    "LLVMXtensaAsmParser",
    "LLVMXtensaDesc",
    "LLVMXtensaInfo",
    "LLVMXtensaCodeGen",
    "LLVMXtensaDisassembler",

Fixing linking undefined references.

-Dllvm_has_xtensa (old flag)

Currenty (v0.12.0-dev), -Dllvm-has-xtensa

Reference

• master...kassane:zig:xtensa (need espressif fork) v0.12.0-dev

[aykevl]

What about the linker? I don't think these patches include patches for the linker right? So you would still have to use the GCC linker that Xtensa provides :(

@FireFox317 I implemented linker support a while ago: espressif/llvm-project#53

[Borderliner]

I'd love to see a more straightforward approach to compiling a zig app for my ESP32

[alexrp]

The main issue here is that LLVM's Xtensa target is experimental. To my knowledge, historically, experimental targets have not been enabled in released Zig binaries. So this is really just a question of when Xtensa graduates to being a supported target in LLVM. I don't imagine it'll take terribly long since Espressif are actively submitting patches.

That aside, I have a question: Is running Linux on these actually a thing that people do? (I know the kernel has support for Xtensa, but I don't know if it's commonly used vs bare metal.) If yes, I can prioritize adding minimal standard library support for that - namely startup code and std.os.linux arch bits.

[newcomertv]

You wouldn't run linux on an esp32 (Xtensa).
I believe there have been a few crazies that did it but its not really usable.

I somehow ended up on this zig issue so please note I have not written a single line of zig in my life but I've worked with esp32s (among other MCUs) and have dealt with portability issues for some time now:

The best bet is to allow for various "std" targets as different projects run on different os's.

Until now all my esp projects have been using esp-idf with FreeRTOS. Here is an example of how rust does some bindings to that: https://github.com/esp-rs/esp-idf-hal

Zephyr is more cross platform though very niche on something like the esp32. ( yet to meet someone that actually did that in a professional environment )

In general most embedded code isn't very portable since the OS keeps on changing and you need to access hardware which won't be the same.
You can check out the embedded-hal, embassy and rtic projects to see how rust attempts to deal with this problem.

Maybe there'll be some cross pollination happening?

Note: Please try to think of timeouts and fallible operations from the get go. MCUs don't care about large numbers crunching or doing stuff as fast as possible. They care about doing it reliably and predictably.

[wiiggee1]

What is the current state of Xtensa support on Zig? Currently looking into using Zig for my Master Thesis for the ESP32 S3. I was wondering, if writing the main logic in Zig would be possible, and then invoke that in a main.cor main.cpp file for running the logic. For instance export my functions using export to the C ABI, then compile using xtensa-esp32s3-elf-gcc toolchain for the main.c executable. Is there currently any way of running your zig code for Xtensa targets or any other workaround for this? Have looked at https://github.com/ziglang/zig/compare/master...kassane:zig:xtensa.

[kassane]

Hi @wiiggee1

Currently looking into using Zig for my Master Thesis for the ESP32 S3

LLVM upstream not have espressif-xtensa targets support. Zig upstream uses LLVM upstream.

See below

• upstream: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.7/llvm/lib/Target/Xtensa/Xtensa.td
• espressif/llvm: https://github.com/espressif/llvm-project/blob/xtensa_release_19.1.2/llvm/lib/Target/Xtensa/Xtensa.td

My fork replace LLVM upstream to espressif/LLVM (WiP) like esp-rs community.

There are currently only two alternatives for you to try Zig on Xtensa.

• 1: https://github.com/kassane/zig-espressif-bootstrap/releases - Zig-xtensa tarballs
• 2: use zig-upstream and try -ofmt=c (with experimental xtensa generic-cpu)

It's also worth giving credit to @andrewrk for facilitating most of the llvm-tablegen reader & generator to include more non-upstream targets.

[wiiggee1]

@kassane Thanks for the fast reply. I'll give both of them a try for the upcoming week (tomorrow). Running your approach, is it just a matter of forking down your repo? Or do I need some other setup? I'll give some updates throughout my master thesis, and the ongoing progress.

Thanks yet again @kassane for the quick reply. I'll probably use this issue thread, for Xtensa related problems.

Yeah credit to @andrewrk for the good work!

[kassane]

@wiiggee1

Running your approach, is it just a matter of forking down your repo?

There is no need fork my project, just use the prebuilt zig-fork with espressif/crosstool-ng (gnu tools) which has better support for linking and serves as the basis for esp-idf solutions.

The espressif/LLVM is far from ideal and support is not 100%, like esp32-s3 SIMD.The new priority of espressif is RISC-V (esp32-p4 - first custom riscv32 from this company).

Sample project: https://github.com/kassane/zig-esp-idf-sample (build.zig + CMake [esp-idf])

Using zig-fork you will be able to generate objects and static-libraries without difficulty, as long as you specify -mcpu=esp32s3 in addition to the xtensa-freestanding target.

[wiiggee1]

@kassane One quick question. Can this zig-fork be coexist with the standard Zig compiler?

[kassane]

Can this zig-fork be coexist with the standard Zig compiler?

@wiiggee1 - Only difference between fork and upstream is espressif mcpu= added to xtensa target.

[wiiggee1]

@kassane I would love to learn more from you, and what happens behind the scene for this to work. So if I understand this correctly, is to only curl the tarball from https://github.com/kassane/zig-espressif-bootstrap/releases. Then just define my mcpu xtensa target during my build.zig setup?

[kassane]

@wiiggee1

Then just define my mcpu xtensa target during my build.zig setup?

Exactly.