5 ms·

I am excited about Nim because it compiles to C that can run on an ARM microcontroller. I believe this was a possibility at some point, but I don't know if thi

I am excited about Nim because it compiles to C that can run on an ARM microcontroller. I believe this was a possibility at some point, but I don't know if this is a priority for Araq. So (personally) I see it as a (potential) "C replacement for embedded systems".

detaro 12y ago
Won't Rust and Go likely get there equally easy?
- eaurouge 12y ago
  Nim compiles down to C and can produce code to run directly on bare metal. My understanding is that Go and Rust (to a lesser degree) require a runtime. Perhaps someone with better knowledge of all three languages could chime in.
  - samatman 12y ago
    Rust's runtime has been reduced to bounds-checking of array access, IIRC. So to a much lesser degree, and I believe Nim also provides this behavior by default. Go is garbage collected and has an opinionated ABI and runtime. Completely different beasts.
    - haberman 12y ago
      Yes, agreed, though I really wish Rust could compile to C: http://www.reddit.com/r/rust/comments/2e8t9k/my_1_wish_list_item_for_rust_robust_compiling_to/ http://www.reddit.com/r/rust/comments/2e8t9k/my_1_wish_list_... Someone has revived the LLVM C Backend. Hopefully this could be a path to Rust->C compilation: https://github.com/draperlaboratory/llvm-cbe https://github.com/draperlaboratory/llvm-cbe Compiling to C is so important to me that I may check out Nim as an alternative to Rust, despite liking Rust very much.
  - FreeFull 12y ago
    Rust has been used to write code that runs on bare metal too. Typically, this is done by using #![no_std], since the standard library depends on things like jemalloc and libc stuff. Everything that doesn't depend on these is in libcore.
the_real_bto 12y ago
I like this use case. I've had the misfortune of trying to cross compile Python for ARM. It's very difficult, because the build process runs the freshly compiled python executable. This obviously doesn't work when you are compiling an ARM executable on an x86 machine. The answer for us was to use Scratchbox [0]. This let us run the compilation on an emulated ARM machine. In case anyone is wondering: The actual platform was Chumby [1], and Python ran great on it. We had a little twisted [2] application that displayed images and played sound. To display the images we just wrote an image file (after using PIL to manipulate it) to /dev/fb. It was really fun! I just double checked the hardware the chumby: A 350 MHZ ARM9 processor with 64 megabytes of SDRAM. It sounds a little crazy to me now to think of transforming images using PIL in 64 megabytes of ram, but it actually worked quite well. [0] http://www.scratchbox.org/ http://www.scratchbox.org/ [1] http://en.wikipedia.org/wiki/Chumby http://en.wikipedia.org/wiki/Chumby [2] https://twistedmatrix.com/trac/ https://twistedmatrix.com/trac/
haberman 12y ago
I'm just trying Nim for the first time. How do you compile to totally self-contained C? I tried pulling the files out of nimcache/*.c, but it is wanting to include nimbase.h. Is there a way to compile an entire Nim program to a single self-contained .c file (ie. an amalgamation, aka SQLite?)
- mmfZ4e4OqQ7RRwP 12y ago
  You copy the nimbase.h file along with the nimcache/*.c files. That's it. The compiler doesn't do it because it's a waste of time/space copying a file which you most likely can include from somewhere else, and it's not a generated file.
  - haberman 12y ago
    Good to know. It would be nice if there was an option for the compiler to build a single .c file that was totally self-contained, for distribution purposes.
    - mmfZ4e4OqQ7RRwP 12y ago
      I don't know anybody who redistributes source code as a single C file, but you could try concatenating the files into one. Usually people redistributing source code don't mind having several files bound together by some make|build script. The nim compiler has the --genScript switch to make one. Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.
      - haberman 12y ago
        > I don't know anybody who redistributes source code as a single C file SQLite pioneered this approach, called an Amalgamation. It offers some noticeable advantages: https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html It is gaining some followers: https://github.com/vinniefalco/Amalgamate https://github.com/vinniefalco/Amalgamate http://stackoverflow.com/questions/2719311/tool-to-create-an-amalgamation-combine-all-source-files-of-a-library-into-one-fo http://stackoverflow.com/questions/2719311/tool-to-create-an... http://lua-users.org/lists/lua-l/2008-08/msg00594.html http://lua-users.org/lists/lua-l/2008-08/msg00594.html > Usually people redistributing source code don't mind having several files bound together by some make|build script. A single .c file is easier to integrate into various build systems. For example a Visual Studio project, or another Makefile without needing a separate script. It's just cleaner. > Most people willing to get something redistributable prefer a binary static|dynamic library or final executable. These aren't portable like a C source file is.
vardump 12y ago
That's truly exciting. I wonder how well it'd run on Altera Nios 2 with, say, 16 kB of RAM. If Nim works well for that case, I'll start to use it yesterday!

detaro 12y ago

Won't Rust and Go likely get there equally easy?

eaurouge 12y ago
Nim compiles down to C and can produce code to run directly on bare metal. My understanding is that Go and Rust (to a lesser degree) require a runtime. Perhaps someone with better knowledge of all three languages could chime in.
- samatman 12y ago
  Rust's runtime has been reduced to bounds-checking of array access, IIRC. So to a much lesser degree, and I believe Nim also provides this behavior by default. Go is garbage collected and has an opinionated ABI and runtime. Completely different beasts.
  - haberman 12y ago
    Yes, agreed, though I really wish Rust could compile to C: http://www.reddit.com/r/rust/comments/2e8t9k/my_1_wish_list_item_for_rust_robust_compiling_to/ http://www.reddit.com/r/rust/comments/2e8t9k/my_1_wish_list_... Someone has revived the LLVM C Backend. Hopefully this could be a path to Rust->C compilation: https://github.com/draperlaboratory/llvm-cbe https://github.com/draperlaboratory/llvm-cbe Compiling to C is so important to me that I may check out Nim as an alternative to Rust, despite liking Rust very much.
- FreeFull 12y ago
  Rust has been used to write code that runs on bare metal too. Typically, this is done by using #![no_std], since the standard library depends on things like jemalloc and libc stuff. Everything that doesn't depend on these is in libcore.

the_real_bto 12y ago

I like this use case. I've had the misfortune of trying to cross compile Python for ARM. It's very difficult, because the build process runs the freshly compiled python executable. This obviously doesn't work when you are compiling an ARM executable on an x86 machine. The answer for us was to use Scratchbox [0]. This let us run the compilation on an emulated ARM machine. In case anyone is wondering: The actual platform was Chumby [1], and Python ran great on it. We had a little twisted [2] application that displayed images and played sound. To display the images we just wrote an image file (after using PIL to manipulate it) to /dev/fb. It was really fun! I just double checked the hardware the chumby: A 350 MHZ ARM9 processor with 64 megabytes of SDRAM. It sounds a little crazy to me now to think of transforming images using PIL in 64 megabytes of ram, but it actually worked quite well. [0] http://www.scratchbox.org/ http://www.scratchbox.org/ [1] http://en.wikipedia.org/wiki/Chumby http://en.wikipedia.org/wiki/Chumby [2] https://twistedmatrix.com/trac/ https://twistedmatrix.com/trac/

haberman 12y ago

I'm just trying Nim for the first time. How do you compile to totally self-contained C? I tried pulling the files out of nimcache/*.c, but it is wanting to include nimbase.h. Is there a way to compile an entire Nim program to a single self-contained .c file (ie. an amalgamation, aka SQLite?)

mmfZ4e4OqQ7RRwP 12y ago
You copy the nimbase.h file along with the nimcache/*.c files. That's it. The compiler doesn't do it because it's a waste of time/space copying a file which you most likely can include from somewhere else, and it's not a generated file.
- haberman 12y ago
  Good to know. It would be nice if there was an option for the compiler to build a single .c file that was totally self-contained, for distribution purposes.
  - mmfZ4e4OqQ7RRwP 12y ago
    I don't know anybody who redistributes source code as a single C file, but you could try concatenating the files into one. Usually people redistributing source code don't mind having several files bound together by some make|build script. The nim compiler has the --genScript switch to make one. Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.
    - haberman 12y ago
      > I don't know anybody who redistributes source code as a single C file SQLite pioneered this approach, called an Amalgamation. It offers some noticeable advantages: https://www.sqlite.org/amalgamation.html https://www.sqlite.org/amalgamation.html It is gaining some followers: https://github.com/vinniefalco/Amalgamate https://github.com/vinniefalco/Amalgamate http://stackoverflow.com/questions/2719311/tool-to-create-an-amalgamation-combine-all-source-files-of-a-library-into-one-fo http://stackoverflow.com/questions/2719311/tool-to-create-an... http://lua-users.org/lists/lua-l/2008-08/msg00594.html http://lua-users.org/lists/lua-l/2008-08/msg00594.html > Usually people redistributing source code don't mind having several files bound together by some make|build script. A single .c file is easier to integrate into various build systems. For example a Visual Studio project, or another Makefile without needing a separate script. It's just cleaner. > Most people willing to get something redistributable prefer a binary static|dynamic library or final executable. These aren't portable like a C source file is.

vardump 12y ago

That's truly exciting. I wonder how well it'd run on Altera Nios 2 with, say, 16 kB of RAM. If Nim works well for that case, I'll start to use it yesterday!