1. I found a critical bug almost immediately, but Andreas fixed it within 24 hours, and was super helpful.
2. Once the issue was resolved, it was surprisingly straight forward to get it running. I started by wrapping the arduino libs, and quickly shifted to wrapping the AVR libraries directly.
One take away was: Nim (and Julia) are likely really nice languages to run in these sort of low-level environments.
Another take away: there's an opportunity to develop a low-level C-based library to better support efforts like this. Both AVR and Arduino libraries weren't designed to be wrapped in something like Nim. And the Arduino codebase could use a healthy refactoring.
So could Nim's stdlib and compiler backend, but the leaders have no intention of doing that, and never have, which is why there is a hard fork.
The C++ 'new' operator does seem to be supported, so I assume it has some kind of heap allocator - although I imagine that when you've only got 1 kilobyte to play with it gets quickly eaten by the allocators datastructures and C++ vtable pointers, not to mention the impact of fragmentation if you allocate any objects more than a few tens of bytes.
In any case, when all we have is 1 KB, the real answer is Assembly.
C++ really isn't my forte though.
You can also overload it, so that it can be given as implicit parameter.
Modern C++ compilers are also able to do escape analysis and remove new altogether,
https://godbolt.org/z/f9vnxG88K
If you try AVR instead of X64, the optimization will be missing, which is only a side effect of the backend not having as much attention in what it looks into.
[1]: https://microcontrollerslab.com/use-freertos-arduino/
[2]: https://github.com/analytech-solutions/CBinding.jl
[3]: https://www.mathworks.com/help/supportpkg/arduino/run-on-tar...
I don't think CBinding.jl is an option, since the whole point of the arduino is that the julia runtime can't run there (and doesn't fit in the first place - there's not enough RAM and swapping to the SD seems bad). Linking with C created .o files should work though?
I don't own any ESP32, but if that happens, yes I'd very much like to try!
I think CBinding.jl could be helpful if one wanted to write a target-specific shim library in C and link against it. I would expect that some of the glue is going to be easier to write in C than in Julia, and you can play some tricks with macros to create bare modules [1] within some kind of `@arduino_setup`/`@arduino_loop`-style blocks.
Edit: By the way, those target-specific shims might already exist as part of the Arduino IDE. PlatformIO [2] is also another possible collider of these types of platform-specific glues.
[1]: https://docs.julialang.org/en/v1/manual/modules/#Default-top...
[2]: https://docs.platformio.org/en/latest/boards/index.html
Yeah, this was mostly an experiment to see what kinds of problems I run into - I didn't expect this to actually work out! It's still very finicky, relying on LLVM to remove dead runtime calls and so on, but non-allocating stuff with immutables should work, though I haven't actually tested it.
Just goes to show how important it can be to read code in completely different fields than the one you're working in. Some problems are common for others so they've already been solved. Knowing that a solution exists is half the battle.
Conveniently, it's also pretty easy to check how any LLVM IR you've added manually with `llvmcall` is fitting in with the Julia-generated IR around it using `@code_llvm`.
Want to see Rust on that new m68k backend or 6502 backend mostly out of morbid curiosity.
https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
One example among many others.
