ulisp-builder VS llvm-project

There is a uLisp Builder that generates platform-specific builds from a single codebase.

> The uLisp Builder is a set of programs written in Common Lisp to allow you to build a version of uLisp for a particular platform from a common repository of source files.

> The aim of the Builder was to make it easier to maintain uLisp across multiple platforms. Where the C function for a particular uLisp feature is identical on all platforms there is just a single occurrence of that source in the Builder repository.

uLisp Builder - http://www.ulisp.com/show?3F07

GitHub repo - https://github.com/technoblogy/ulisp-builder

---

uLisp for STM32 boards - http://www.ulisp.com/show?29ST

Repo - https://github.com/technoblogy/ulisp-stm32

I'm a big fan of uLisp, got it running on an ESP8266. Love how the whole language fits in a single file, making it easy to hack around.

Recently I learned how the author generates the uLisp variants for different platforms using Common Lisp:

https://github.com/technoblogy/ulisp-builder

..And an accompanying article to describe how it works:

uLisp Builder - http://www.ulisp.com/show?3F07

Also, a treasure trove of other Arduino and AVR projects by the author here:

http://www.technoblogy.com/

I forgot to say that I use this llvm build. Just download the release and point the clangd server to it.

Xtensa support (esp32). Will be interesting how this will be for Rust and Zig support for esp32

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

https://www.phoronix.com/news/LLVM-Xtensa-Backend

https://github.com/espressif/llvm-project/issues/4#issuecomm...

https://github.com/ziglang/zig/issues/5467#issuecomment-1465...

Hopefully, in the future the installation will be simpler, as we are trying to upstream our LLVM changes (first 10 patches are already accepted!), and once we manage to upstream LLVM changes we will proceed with upstreaming our Rust fork changes.

The main discussion can be led back to this GitHub issue and this comment; fortunately, we don't need to build espressif's llvm fork anymore as they supply the clangd (this is the language server we need) and you can find the zip here. I'll briefly list down the steps required to set up vim with clangd to take advantage of clangd's features (auto-completion, linting, code refactoring ...)

In my case, it's pretty annoying that the Xtensa platform doesn't have official LLVM support. It's in progress but going very slowly.

The link to the espressive issue trackers: https://github.com/espressif/llvm-project/issues/4

Xtensa. They've got a fork of LLVM that supports it that they're working toward getting upstreamed. The community has a fork of rustc that uses it (and a quickstart crate) while we wait for it to get upstreamed.

https://github.com/espressif/llvm-project/issues/4 is a good example why updating llvm isn't easy and takes a lot of time.

Just to clarify - Gambit, Chicken, and Carp all compile to portable C.

I hadn't realized LLVM mainline doesn't support Xtensa. I'm surprised.

D does support Xtensa via LDC (https://forum.dlang.org/thread/[email protected]...). It looks like GDC also nearly supports it, requiring only a minor patch at present.

A functioning LLVM backend does exist (https://github.com/espressif/llvm-project/issues/4) and might be making very slow progress towards being merged. A quick search shows that it works for Rust. I suspect (but don't know) that it might work for Terra as well.

There's also the LLVM C backend (https://github.com/JuliaComputingOSS/llvm-cbe) but I've no idea how efficient such an approach is when applied to real world embedded tasks.