FYI: 16-bit support in LLVM; any idea if easy to support it/8-bit micros/MCUs in Julia?

I just noticed people are planning to add support for 8-bit AVR in Rust:

I’m kind of amazed people bother for such a new language (while I can see it more relevant there).

I’m just curious could it be much difficult for Julia? Maybe less since Julia is generic by default? Just curious, would rather first see good support for ARM on MCUs; and on supercomputers, since November there’s one ARM-based on TOP500 ranked 204th:

https://www.top500.org/system/179565

and then:

https://www.top500.org/news/sandia-to-install-first-petascale-supercomputer-powered-by-arm-processors/

[16-bit pointers or for base index seems not worth it. Using 32-bit base index seems like a sweet spot, even valuable on supercomputers… and not too bad on MCUs, where 16-bit pointers are only about supporting certain hardware, not clear 16-bit pointers are better there.]

This would be possible but a lot of work. There are many places where it’s assumed that the only possible word sizes are 32 and 64 bit. That said, it would mostly be tedious work tracking down those places and generalizing them. Unlikely to happen, however, unless someone who really wants it does the work. Even then, without CI for such systems the support would bitrot really quickly.

3 Likes

The CI issue could be “solved” with a software emulator. However, I’m less convinced that this will be just a (rather involved) find-and-replace, because even if you could technically execute some Julia code on an MCU, what happens when you need to JIT compile something type-unstable, or make a system call? You’d need a ton of hooks to make sure all of these get forwarded out of the MCU and onto the host (assuming one is still attached!), or instead only run very small portions of your code on the MCU (which becomes essentially an AOT problem that is still WIP for Julia, even on powerful host systems).

MCUs were designed to operate in constrained environments, and so the code you run on it needs to be constrained in some way to fit within the available resource budget. Julia is not a language that I would consider “constrained”; there are a lot of magical and powerful things you can do, but you do pay the price in terms of compilation overhead and extra memory usage.

2 Likes

Do you know how long the Julia test suite takes to run on non-emulated hardware? Of course, this could run only daily instead of on each PR, so yes, I suppose that’s possible.

Re MCUs: I wasn’t really addressing MCUs specifically, just the possibility of running on 16-bit systems.

1 Like

Hence solved in quotes :slight_smile: And I doubt even daily tests would be wise; it would likely take days to complete on (emulated) 16/8-bit MCU hardware.

I’m focusing on the MCU aspect because:

  1. There have been a number of other Discourse posts asking almost exactly the same thing recently
  2. I don’t know of any hardware in common usage today that’s less than 32-bit, other than MCUs
  3. I know a small bit about MCUs (a very small bit)

I know absolutely nothing about MCUs so I’ll leave that up to you :smile:

I don’t think this post is about seriously considering porting Julia to anything concrete; it looks more like an idle question.

1 Like

In that case, in favor of keeping down the noise from duplicate posts, can we lock further threads like these (about Julia and MCUs) unless people actually put forward plans/PRs/packages to accomplish this goal? A simple search for MCU or microcontroller would likely turn up those previous posts and their associated discussions.

1 Like

For reference:

It might be possible to write a julia → nim / chapel transpiler, which then could compile to C/C++, and then you would give it to the arduino IDE to compile for the MCU. Errors would be a bit of a headache though, and the 8-bit environment is usually very constrained, ie 2K ram and 16/32K of program storage is probably at the higher end

It seems avr32 may be able to run older linux kernels, but a raspberry pi zero would probably be cheaper and far better supported (at 10$ delivered here i may even get myself one from santa… )

I’m not saying a transpiler to Nim or Chapel wouldn’t be interesting (for non-16-bit, non-MCU reasons), but why not straight to C (or possibly machine code/assembly with PackageCompiler.jl where possible e.g. for ARM)? It was already possible. Why not again just use Intel’s Julia2C (yes, it’s bitrotten by now it seems, but should/could be made to work again?):

[FYI: Intel’s ParallelAccelerator has also partial C++ translation (not its main point, parallelism is and C++ incidental). It may even work currently or at least be less bitrotten.]

My questions here are kind of rhetorical while you want to answer them in the other MCU threads. I’m ok with locking this thread that I started. I’ve gotten my question answered (and some discussion).

2 Likes