I did see ARMv6M mentioned for LLVM, so then according to you Julia (without the runtime) would work, no “if”. But below is mostly speculation on running even with the runtime.
Looking at the julia “binary” (main) it’s only 22472 bytes, so far so good. But even with just the first dependency, libjulia.so.1.8 at 229 KB, the combination is already close to the the RAM budget at 251 KB (it’s unclear that code needs to fit in RAM, or just the larger 8 MB flash).
But there are many more dependencies, most larger than the RAM each so seems like an impossible task, BUT I just list the largest ones in order (and I only list those I’m confident can be eliminated):
-rwxr-xr-x 1 pharaldsson pharaldsson 221M sep 6 21:50 sys.so
-rwxr-xr-x 1 pharaldsson pharaldsson 79M sep 6 21:39 libLLVM-13jl.so
-rwxr-xr-x 1 pharaldsson pharaldsson 42M sep 6 21:51 libjulia-codegen.so.1.8
-rwxr-xr-x 1 pharaldsson pharaldsson 32M sep 6 21:39 libopenblas64_.0.3.20.so
-rwxr-xr-x 1 pharaldsson pharaldsson 18M sep 6 21:39 libstdc++.so.6.0.29
-rwxr-xr-x 1 pharaldsson pharaldsson 11M sep 6 21:51 libjulia-internal.so.1.8
-rwxr-xr-x 1 pharaldsson pharaldsson 8,7M sep 6 21:39 libgfortran.so.5.0.0
-rwxr-xr-x 1 pharaldsson pharaldsson 2,7M sep 6 21:39 libblastrampoline.so.5.0.2
-rwxr-xr-x 1 pharaldsson pharaldsson 2,3M sep 6 21:39 libmpfr.so.6.1.0
-rwxr-xr-x 1 pharaldsson pharaldsson 1,6M sep 6 21:39 libgit2.so.1.3.0
[..]
-rwxr-xr-x 1 pharaldsson pharaldsson 981K sep 6 21:39 libquadmath.so.0.0.0
-rwxr-xr-x 1 pharaldsson pharaldsson 745K sep 6 21:39 libumfpack.so.5.7.9
-rwxr-xr-x 1 pharaldsson pharaldsson 726K sep 6 21:39 libnghttp2.so.14.22.0
-rwxr-xr-x 1 pharaldsson pharaldsson 698K sep 6 21:39 libgmp.so.10.4.1
-rwxr-xr-x 1 pharaldsson pharaldsson 643K sep 6 21:39 libpcre2-8.so.0.11.0
-rwxr-xr-x 1 pharaldsson pharaldsson 638K sep 6 21:39 libcurl.so.4.8.0
-rwxr-xr-x 1 pharaldsson pharaldsson 638K sep 6 21:39 libmbedcrypto.so.2.28.0
[..]
-rwxr-xr-x 1 pharaldsson pharaldsson 466K sep 6 21:39 libgcc_s.so.1
-rwxr-xr-x 1 pharaldsson pharaldsson 305K sep 6 21:39 libmbedtls.so.2.28.0
-rwxr-xr-x 1 pharaldsson pharaldsson 303K sep 6 21:39 libssh2.so.1.0.1
-rwxr-xr-x 1 pharaldsson pharaldsson 222K sep 6 21:39 libopenlibm.so.4.0
-rwxr-xr-x 1 pharaldsson pharaldsson 209K sep 6 21:39 libklu.so.1.3.8
-rwxr-xr-x 1 pharaldsson pharaldsson 203K sep 6 21:39 libspqr.so.2.0.9
-rwxr-xr-x 1 pharaldsson pharaldsson 184K sep 6 21:39 libmbedx509.so.2.28.0
-rwxr-xr-x 1 pharaldsson pharaldsson 139K sep 6 21:39 libatomic.so.1.2.0 ???
-rwxr-xr-x 1 pharaldsson pharaldsson 117K sep 6 21:39 libz.so.1.2.12
[..]
-rwxr-xr-x 1 pharaldsson pharaldsson 11K sep 6 21:39 libsuitesparseconfig.so.5.10.1
You might think you need a e.g. the C standard library (or C++ standard library) but you don’t actually even need those to run programs (just libc, or equivalent, to allow for portable code, not strictly needed).
The largest dependency is the Julia sysimage, sys.so, and it can be made radically smaller (while keeping the Julia runtime, e.g. GC and threads) or just eliminated when StaticCompiler.jl is used (then missing GC for now, and threads).
Note, a 16 KB Hello world binary seems huge to me (we could do it in a few bytes in assembly (or BASIC you could rely on) back in the days; plus the preinstalled OS/BIOS code).
Below I mention Cosmopolitan libc, that seems like off-topic, since it doesn’t target ARM, but it’s probably the smallest C library, or at least the the only supporting many operating systems at the same time, and tiny doing that. So it’s good to try to support Julia with it besides it does work on ARM too (through emulation, yes, not ideal for a microcontroller).
It can run “everywhere” (so ARM too) even in web browser: Actually Portable Executable
The most compelling use case for making x86-64-linux-gnu as tiny as possible, with the availability of full emulation, is that it enables normal simple native programs to run everywhere including web browsers by default.
Cosmopolitan makes C a build-once run-anywhere language, similar to Java
[..]
# ~40kb static binary (can be ~16kb w/ MODE=tiny)
./hello.comThe above command fixes GCC so it outputs portable binaries that will run on every Linux distro in addition to Mac OS X, Windows NT, FreeBSD, OpenBSD, and NetBSD too. For details on how this works, please read the αcτµαlly pδrταblε εxεcµταblε blog post. This novel binary format is also optional, since
hello.com.dbgis executable too, only on your local system since it’s an ELF binary.
αcτµαlly pδrταblε εxεcµταblε Actually Portable Executable
I found out that it’s possible to encode Windows Portable Executable files as a UNIX Sixth Edition shell script, due to the fact that the Thompson Shell didn’t use a shebang line. Once I realized it’s possible to create a synthesis of the binary formats being used by Unix, Windows, and MacOS, I couldn’t resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps. Here’s how it works:
[..]
In the above one-liner, we’ve basically reconfigured the stock compiler on Linux so it outputs binaries that’ll run on MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS. [..]Platform Agnostic C / C++ / FORTRAN Tooling
Who could have predicted that cross-platform native builds would be this easy? As it turns out, they’re surprisingly cheap too. Even with all the magic numbers, win32 utf-8 polyfills, and bios bootloader code, exes still end up being roughly 100x smaller than Go Hello World:
[12 KB executable that runs on all platforms]
[..]x86-64 Linux ABI Makes a Pretty Good Lingua Franca
[..]
It’ll be nice to know that any normal PC program we write will “just work” on Raspberry Pi and Apple ARM. All we have to do embed an ARM build of the emulator above within our x86 executables, and have them morph and re-exec appropriately, similar to how Cosmopolitan is already doing doing with qemu-x86_64, except that this wouldn’t need to be installed beforehand. The tradeoff is that, if we do this, binaries will only be 10x smaller than Go’s Hello World, instead of 100x smaller. The other tradeoff is the GCC Runtime Exception forbids code morphing, but I already took care of that for you, by rewriting the GNU runtimes.
[..]
bash hello.com # runs it natively
./hello.com # runs it natively
./tinyemu.com hello.com # just runs program
./emulator.com -t life.com # show debugger gui
echo hello | ./emulator.com sha256.elf
[..]
DESCRIPTION
Emulates x86 Linux Programs w/ Dense Machine State Visualization
Please keep still and only watchen astaunished das blinkenlights
A bunch of almost unbelievably clever tech tricks come together into something practical with redbean 2: a webserver plus content in a single file that runs on any x86-64 operating system.
The project is the culmination – so far – of a series of remarkable, inspired hacks by programmer Justine Tunney: αcτµαlly pδrταblε εxεcµταblε, Cosmopolitan libc, and the original redbean. It may take a little time to explain what it does, so bear with us. We promise, you will be impressed.
To begin with, redbean uses a remarkable hack known as APE, which stands for Actually Portable Executable – which its author styles αcτµαlly pδrταblε εxεcµταblε. (If you know the Greek alphabet, this reads as “actmally pdrtable execmtable”, but hey, it looks cool.)
[Wow, that actually reads as “actually portable executable”, µ meant as u, not m[u]; δ is also just stylized o, not d[elta]. Maybe they’re trying to be helpful, or just missed the point of the Greek. I like that Justine is getting publicity, in this otherwise good Register article, and other news.]
[..]
Given this interest in programs that can be booted directly, without an OS at all, it may not surprise you that a future goal for redbean is to make it bootable: to embed a TCP/IP stack and network-card drivers, for a completely standalone tool.
It doesn’t (at least currently) support threads:
I don’t see that threads couldn’t be supported portably across (those) operating systems targeted (though likely not easily from the BIOS, then you’re basically shipping an OS with the libc), but threads aren’t always a requirement. Thread support is likely a requirement of Julia runtime, just as it is now for Python (as of recently), even though you run with only one thread. I guess the thread support code could be fully disabled/removed in Julia.
StaticTools.jl already has a println equivalent (that works without the GC/runtime). Not that I see println most useful for microcontrollers.