An organization for bringing Julia to embedded processors.
- Building executable
- Making lib/dll libraries.
- A lot of the drivers and libraries are written in C, so we also can try embedding Julia in an already written C code (like writing the main computational function in Julia).
- Building on desktop (Windows, etc) for ARM.
Julia is a high-level language with convenient interfaces for libraries in other languages (e.g. C, C++, etc), and also it is possible to embed Julia in an already written project.
We were interested to try to build and try some programs using Julia for embedded processors. Also, make some examples for others to use as templates for embedded programming in different situations. As Julia 1.2 added 32bit binaries we decided to start this work:
- all of the ARM Cortex-M processors (https://en.wikipedia.org/wiki/ARM_Cortex-M) which are highly used in many embedded applications are 32 bit.
- all of the ARM Cortex-R processors (https://en.wikipedia.org/wiki/ARM_Cortex-R) for mission-critical applications are 32 bit.
- a lot of ARM Cortex-A processors are 32 bit (https://en.wikipedia.org/wiki/ARM_Cortex-A). However, this work will be useful for any embedded system.
https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/27
Here are some miscellaneous notes on cross-compiling and static compilation in Julia:
-
CUDAnative -- CUDAnative is the state of the art for cross-compiling to a limited platform. It uses LLVM.jl to help generate appropriate LLVM code. I've copied the approach for WebAssembly (still very limited or nonworking). This approach is also being used for AMD GPU's. This approach works great, but compatible Julia code is very limited. There has been the talk of separating out the codegen portions of CUDAnative into a separate package, but it hasn't happened, yet.
-
PackageCompiler / tree shaking -- The approach to static compilation that runs the most code is probably with something like PackageCompiler. Tree shaking is a way to reduce the size of the compiled system image. See this for more information. The main hurdles with this approach are that tree-shaking doesn't exist, and it's not set up for cross-compilation.
-
Codegen advances -- Jameson is working on changes to allow the CUDAnative approach to compile more code: JuliaLang/julia#25984.
-
LLVM support -- Julia's version of LLVM doesn't include targets of interest for embedded applications.(https://github.com/maleadt/LLVM.jl)
-
libjulia -- If used,
libjulia
will need to be cross-compiled. Another option is to write a more minimal version oflibjulia
(hopefully in Julia), and swap out theccall
s tolibjulia
functions as needed. -
ccalls and cglobal -- When Julia compiles code CUDAnative style,
ccall
andcglobal
references get compiled to a direct pointer. These need to be converted to symbol references for later linking. Prototype described here. -
Global variables -- A lot of code gets compiled with global variables, and these get compiled to a direct pointer. One way to handle this is with a serialize/deserialize approach. Prototype described here.
-
Initialization -- If
libjulia
is used, some init code needs to be run to set up GC and other things. It's not clear how to do that from outside. May need PR's to base Julia to help here.
https://github.com/JuliaInterop/Clang.jl
https://github.com/JuliaInterop/CEnum.jl
https://github.com/JuliaInterop/CxxWrap.jl
https://github.com/JuliaInterop/libcxxwrap-julia
https://github.com/JuliaInterop/Cxx.jl
https://github.com/JuliaComputing/llvm-cbe
https://github.com/maleadt/LLVM.jl
https://github.com/uraimo/buildSwiftOnARM
https://github.com/uraimo/SwiftyGPIO