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:
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:
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:
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:
- 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 physical 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 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).
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 smallest high-level GC language, smallar than the “tiniest organic creature”, which at 613 bytes would not fit on a boot sector):
δzd Encoding
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_PhrasebookOffset2which 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 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 and BASIC to be the tiniest programming language in the world.