Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Julia bare-metal on an Arduino

seelengrab.github.io

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Running Julia bare-metal on an Arduino

#11

Post by Sukera »

londons_explore wrote: post #8

The default arduino toolchain, which is a g++ wrapper, supports C++, even though the whole system only has only 1 kilobyte of RAM. 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 fragmentatio…

I'm not as familiar with how C++ does allocations compared to julia, but I'd imagine the limitations would be similar - if `new` can allocate memory on the stack, I can't imagine why it wouldn't work out of the box.

C++ really isn't my forte though.

Re: Running Julia bare-metal on an Arduino

#12

Post by pjmlp »

londons_explore wrote: post #8

The default arduino toolchain, which is a g++ wrapper, supports C++, even though the whole system only has only 1 kilobyte of RAM. 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 fragmentatio…

With placement new you don't need an heap, and using C++ doesn't require to use classes, there is still so much improvements over bare bones C.

In any case, when all we have is 1 KB, the real answer is Assembly.

Re: Running Julia bare-metal on an Arduino

#13

Post by wiremine »

Off topic but related: I played around with getting Nim running on an Arduino.

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.

Re: Running Julia bare-metal on an Arduino

#14

Post by pjmlp »

Sukera wrote: post #11
londons_explore wrote: post #8

The default arduino toolchain, which is a g++ wrapper, supports C++, even though the whole system only has only 1 kilobyte of RAM. 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 fragmentatio…

I'm not as familiar with how C++ does allocations compared to julia, but I'd imagine the limitations would be similar - if `new` can allocate memory on the stack, I can't imagine why it wouldn't work out of the box. C++ really isn't my forte though.

With placement new you can allocate wherever you want, as the memory region is one of the parameters.

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.

Re: Running Julia bare-metal on an Arduino

#15

Post by londons_explore »

pjmlp wrote: post #14
Sukera wrote: post #11

Earlier quoted context omitted.

I'm not as familiar with how C++ does allocations compared to julia, but I'd imagine the limitations would be similar - if `new` can allocate memory on the stack, I can't imagine why it wouldn't work out of the box. C++ really isn't my forte though.

With placement new you can allocate wherever you want, as the memory region is one of the parameters. 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 at…

If you comment out the delete[] line, it returns the same output. Does that mean leaking memory is undefined behaviour?

Re: Running Julia bare-metal on an Arduino

#16

Post by kurosknight »

Sukera wrote: post #9
alhirzel wrote: post #6

Earlier quoted context omitted.

Would you accept an ESP32 for your edification? No strings attached. Email me 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. Ed…

That'd be awesome, sure! I'll shoot you an email. PlatformIO is nice, yes - I've already been suggested linking/using that, but I haven't looked into it yet. I also haven't worked with that before, so it'd be completely new territory for me.

Hey! Would you be interested in collaborating on this? I have a wide selection of hardware I'd be happy to contribute as well. You can reach me at my username at gmail dot com.

Re: Running Julia bare-metal on an Arduino

#17

Post by pjmlp »

londons_explore wrote: post #15
pjmlp wrote: post #14

Earlier quoted context omitted.

With placement new you can allocate wherever you want, as the memory region is one of the parameters. 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 at…

If you comment out the delete[] line, it returns the same output. Does that mean leaking memory is undefined behaviour?

Leaking memory is always undefined behaviour regardless of the language when talking about manual memory management.

What guarantees can you assure about the state of the application?

In any case, in this specific example for x64 it doesn't matter, because new gets optimized away.

However, if that optimization isn't done, e.g. AVR backend, then nasal daemons will be summoned.

Re: Running Julia bare-metal on an Arduino

#18

Post by amkkma »

wiremine wrote: post #13

Off topic but related: I played around with getting Nim running on an Arduino. 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…

Cool! How big were the emitted nim binaries?

Re: Running Julia bare-metal on an Arduino

#19

Post by j-james »

wiremine wrote: post #13

Off topic but related: I played around with getting Nim running on an Arduino. 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…

Nim also has some pretty good ESP32 bindings: https://github.com/elcritch/nesper

Re: Running Julia bare-metal on an Arduino

#20

Post by hahaitsfunny »

wiremine wrote: post #13

Off topic but related: I played around with getting Nim running on an Arduino. 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…

> 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.

Post reply on HN