# Now that Julia w/o LLVM is a thing, how long before I can run Julia on RPi Pico?

**URL:** <https://discourse.julialang.org/t/now-that-julia-w-o-llvm-is-a-thing-how-long-before-i-can-run-julia-on-rpi-pico/87676>\
**Category:** General Usage\
**Created:** [September 22, 2022, 10:04pm UTC](https://discourse.julialang.org/t/now-that-julia-w-o-llvm-is-a-thing-how-long-before-i-can-run-julia-on-rpi-pico/87676 "2022-09-22T22:04:03Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 23, 2022, 10:20am UTC](https://discourse.julialang.org/t/now-that-julia-w-o-llvm-is-a-thing-how-long-before-i-can-run-julia-on-rpi-pico/87676/5 "2022-09-23T10:20:02Z")

</div>

> [@dlakelan](#):
>
> it’s got 264MB of RAM

You have a typo, that’s actually 1000 times larger, it has “lots of onboard RAM (264KB)”, which is a challenge, not as if 264 MB wasn’t challenge enough. It’s interesting that 256KB is a lot in the embedded world, but tiny elsewhere.

Even with “Dual ARM Cortex-M0+ @ 133MHz” if you get it to work it’s going to be slow for everything you’re used to, only fast (enough) for embedded stuff.

Non-standard (ELKS) Linux can run on 256 KB (not MB) of RAM, but Julia runtime needs larger currently.

Size-wise you can put Julia (compiled binaries, they can be 20 KB) on the that chip, but you would have to use StaticCompiler.jl (and StaticTools.jl), or similar (not as is or PackageCompiler.jl) after it has been made to work for ARMv6M.

I would recommend doing it with Python as here, just with MicroPython (or CiruitPython) distribution:

> [@Successful Static Compilation of Julia Code for use in Production](https://discourse.julialang.org/t/successful-static-compilation-of-julia-code-for-use-in-production/79318):
>
> The [StaticCompiler](https://github.com/tshort/StaticCompiler.jl) package was recently registered. This post records a successful experiment to statically compile a piece of Julia code into a small .so library on Linux, which is then loaded from Python and used in training of a deep learning model. TLDR Static compilation to a stand-alone library does work on Linux but has rather significant restrictions on the functionality available. It is mostly useful for core computational routines. Roughly speaking, if it could be implemented in plai…

Julia supports ARMv8 (tier 2), and ARMv7, but not ARMv6M (while LLVM supports) which only has 16-bit _length_ “Thumb” instructions, ARMv7 has 32-bit, and ARMv8/AArch64 has only 32-bit length instructions.

The biggest challenge:

> **[ARM Cortex-M](https://en.wikipedia.org/wiki/ARM_Cortex-M)**
>
> The ARM Cortex-M is a group of 32-bit RISC ARM processor cores licensed by ARM Limited. These cores are optimized for low-cost and energy-efficient integrated circuits, which have been embedded in tens of billions of consumer devices. Though they are most often the main component of microcontroller chips, sometimes they are embedded inside other types of chips too. The Cortex-M family consists of Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23 The ARM Cortex-M fam...

> there is no memory management unit (MMU). A full-fledged operating system does not normally run on this class of processor.

[That limitation hasn’t stopped [Micro]Python from working.]

But feel free to try, since that would put Julia in the range of working on:

> the “world’s smallest computer” [..] based on the ARM Cortex-M0+ (and including RAM and wireless transmitters and receivers based on photovoltaics) – by University of Michigan researchers at the 2018 Symposia on VLSI Technology and Circuits with the paper “A 0.04mm3 16nW Wireless and Batteryless Sensor System with Integrated Cortex-M0+ Processor and Optical Communication for Cellular Temperature Measurement.” The device is 1/10th the size of IBM’s previously claimed world-record-sized computer

Even the original 1991 Linux according to Linus:

> **[What would you like to see most in minix?](https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/SwRavCzVE7gJ)**

> needs a MMU (sorry everybody)

So I would recommend without an OS (Julia’s runtime depends on one), UNLESS Julia, Julia’s full runtime, could run on something like:

> **[GitHub - ghaerr/elks: Embeddable Linux Kernel Subset - Linux for 8086](https://github.com/ghaerr/elks)**
>
> Embeddable Linux Kernel Subset - Linux for 8086

> - ELKS, a 16-bit no-MMU Linux on Amstrad PC 2086 (thanks @pawoswm-arm)
> - Booting ELKS on an old 286 MB from 1,44MB floppy (thanks @xrayer)

[Note “286 MB” there means Intel 80286 (which has an MMU), and presumably, motherboard, i.e. not to be read as 286 megabytes. I’m not how large it is, but Amstrad “PC2086 has 8086 processor, but it has full 640kB of memory”.]

> The Intel 80286 had a 24-bit address bus and as such had a 16 [MB](https://en.wikipedia.org/wiki/Megabyte) physical [address space](https://en.wikipedia.org/wiki/Address_space), compared to the 1 MB address space of prior x86 processors.

The original IBM PC had “16 KB – 256 KB” but it didn’t run Linux (or barely an OS by modern standards). It used [Intel 8088](https://en.wikipedia.org/wiki/Intel_8088) and it runs the same code as Intel 8086 that ELKS supports.

I’m not sure Julia strictly needs an MMU, only indirectly, since only the OS has access to it. So it seems theoretically possible to run the Julia runtime with GC (though likely cut down, e.g. no threads, no LLVM/compiler, maybe with the interpreter `--compile=min` [and/]or just compiled binaries).

[https://www.spinics.net/lists/linux-8086/msg00111.html](https://www.spinics.net/lists/linux-8086/msg00111.html)

> I remember there being an option in the ELKS  
> configuration about how many 64 KB memory pages were  
> necessary, and the minimum was 4 (256 KB).

A bit off-topic, though maybe not in this context (linked from ELKS, Justine is awesome, and her [SectorLISP](https://github.com/jart/sectorlisp) smallest high-level GC language, smallar than the “tiniest organic creature”, which at 613 bytes would not fit on a boot sector):

> ## [δzd Encoding](https://justine.lol/sizetricks/#dzd)
> 
> One of the most size optimized pieces of code in the Cosmopolitan codebase is Python. This is where we really had to go beyond code golfing and pull out the artillery when it comes to size coding. One of the greatest weapons in our arsenal (which helped us get statically linked Python binaries down to 2mb in size) is what we call the Delta Zig-Zag Deflate compression scheme, or δzd for short.  
> [..]  
> One of the many symbols in the Python codebase that needed this treatment is `_PyUnicode_PhrasebookOffset2` which was originally 178kb in size, but apply delta encoding, zig-zag encoding, and then finally DEFLATE, we got it down to 12kb. That’s a nearly 10x advantage over DEFLATE’s Huffman encoding alone, and BZIP2’s Burrows-Wheeler transform!

> [SectorLISP](https://github.com/jart/sectorlisp) now supports garbage collection. This is the first time that a high-level garbage collected programming language has been optimized to fit inside the 512-byte boot sector of a floppy disk. Since we only needed 436 bytes, that means LISP has now outdistanced [FORTH](https://github.com/cesarblum/sectorforth) and [BASIC](https://github.com/nanochess/bootBASIC) to be the tiniest programming language in the world.

---

_[View the full topic](https://discourse.julialang.org/t/now-that-julia-w-o-llvm-is-a-thing-how-long-before-i-can-run-julia-on-rpi-pico/87676)._