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

Should you Rust in embedded yet?

kazlauskas.me

Post reply on HN
Print view View original

81–90 of 119 posts

Re: Should you Rust in embedded yet?

#81

Post by atilaneves »

bb88 wrote: post #18
Inityx wrote: post #16

Earlier quoted context omitted.

C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. Additionally, most of these people are primarily electrical engineers, and don't have as strong of a background in computer science. They've been using C for decades and it does everything they want, why would they take the time to learn the boundless complexity introduced by a language that offers t…

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones.

> you can actually figure out in your head what the assembly will look like

I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do.

And it's not like the compiler will magically switch to emitting different instructions if you compile the code above as C++...

Re: Should you Rust in embedded yet?

#82

Post by atilaneves »

q3k wrote: post #26
pknopf wrote: post #17

Earlier quoted context omitted.

Let me ask it this way: I'm a higher level programmer. Later in my career I happen to get down to microcontrollers, what would stop me from using C++?

The standard library (with all its' duplicate code resulting from hardcore templating) will blow up your flash space usage significantly, to the point where you will run out of it sooner than you expect. You will spend time finding alternative standard libraries that are size-optimized and you might end up rewriting a lot of what you take for granted in your C++ daily usage. For example, the Arduino environment is C+…

Then don't use the standard library. Don't even link it in.

> Your typical heap-happy usage

Huh? 1990s C++ was typically heap-happy, which is part of the reason Java looks the way it does. Idiomatic modern C++ uses the stack as much as possible. And one can use custom allocators.

Re: Should you Rust in embedded yet?

#83

Post by koffiezet »

_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

I used to work in a space that was once considered to be embedded (POS systems, including some based on low-cost 8bit controllers, m86k based stuff and low-end ARM at the end), and got out of it just before the entire thing was taken over by fast 32bit or even 64bit ARM CPU's, which eventually moved to running stock Linux or Android. As ARM chips become cheaper and cheaper, the low-level embedded fields will shrink further and further, and the line will shift more and more towards running a full-blown OS below the actual applications. I've even encountered a platform marketed as being "realtime" which was running Linux.

It will always be there, micro-controllers are dirt dirt cheap, and in many cases more suited for industrial environments, and realtime will always be there, but it will become more & more specialized. And as you say, once you get down to a certain level the borrow-checker is a useful feature so I expect it won't be such an interesting target for Rust, and this will probably remain C's stronghold.

Re: Should you Rust in embedded yet?

#84

Post by koffiezet »

jononor wrote: post #76
_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

The borrow checker should be quite useful when using tasks and shared resources in an RTOS. Just closures alone is a benefit.

Your compiler adding the execution of an unpredictable amount of CPU instructions at certain points, which can change with new compiler versions? That sounds like an nightmare for realtime applications. Yes, I have been in situations where I had to count the instructions and clock-cycles to meet deadlines.

Re: Should you Rust in embedded yet?

#85

Post by pjc50 »

pknopf wrote: post #21
bb88 wrote: post #18

Earlier quoted context omitted.

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

Ah, I forgot about the assembly. Is assembly important in microcontrollers?

Writing assembly tends to be restricted to the bits where you need it - special function prologues for interrupt handlers, requiring a particular unusual instruction for something, time-sensitive or cycle-accurate "beam racing" code.

Reading assembly is more useful, especially if your platform's debugger isn't very good.

Re: Should you Rust in embedded yet?

#86

Post by pjc50 »

atilaneves wrote: post #82
q3k wrote: post #26

Earlier quoted context omitted.

The standard library (with all its' duplicate code resulting from hardcore templating) will blow up your flash space usage significantly, to the point where you will run out of it sooner than you expect. You will spend time finding alternative standard libraries that are size-optimized and you might end up rewriting a lot of what you take for granted in your C++ daily usage. For example, the Arduino environment is C+…

Then don't use the standard library. Don't even link it in. > Your typical heap-happy usage Huh? 1990s C++ was typically heap-happy, which is part of the reason Java looks the way it does. Idiomatic modern C++ uses the stack as much as possible. And one can use custom allocators.

Not a good fit for systems with small hardware stacks - PIC16 is still in use http://www.microcontrollerboard.com/pic_memory_organization....

Re: Should you Rust in embedded yet?

#87

Post by koffiezet »

atilaneves wrote: post #81
bb88 wrote: post #18

Earlier quoted context omitted.

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones. > you can actually figure out in your head what the assembly will look like I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do. And it's not…

Psychological ones? No, simply the lack of available reliable compilers for some platforms was my problem. I developed POS applications, where C++ would have worked fine, if we had a decent C++ compiler on every platform we wanted to support. Some platforms used GCC, but most used proprietary compilers - where C++ support was completely absent or very scetchy. When you can't use exceptions, the memory allocator is absolute garbage and leaks stuff on it's own and encounter various random compiler bugs, you quickly decide to stick with plain old C. C++ in my experience was an absolute mess when it came to embedded work (note that the last embedded work I did dates back from 2006, so not sure what the current situation is)

Also, C++ uses a lot more memory, which can also be a no-go when you get as little as 32kb for code+data, luckily with in-place execution.

Re: Should you Rust in embedded yet?

#88

Post by gmueckl »

arcticbull wrote: post #69
throwaway84742 wrote: post #58

Earlier quoted context omitted.

Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.

In many ways I would say a non-faulting non-protected read or write from 0x0 is worse than a crashing protected read.

In many ways, generalized statements like this for all possible controllers and software out there are worse than understanding that accessing address 0 from high level code can have its uses and be completely correct. ;)

In a less condescending tone, if some HW designer put control structures at address 0 and they are writeable, then you have to deal with it in software. If there is no MMU that can remap that memory range, you will end up having legitimate memory accesses to that area. They can only be distinguished from accidental null pointer dereferences by context. This context would need to come from the developer by annotating the source somehow.

Re: Should you Rust in embedded yet?

#89

Post by lvh »

koffiezet wrote: post #84
jononor wrote: post #76

Earlier quoted context omitted.

The borrow checker should be quite useful when using tasks and shared resources in an RTOS. Just closures alone is a benefit.

Your compiler adding the execution of an unpredictable amount of CPU instructions at certain points, which can change with new compiler versions? That sounds like an nightmare for realtime applications. Yes, I have been in situations where I had to count the instructions and clock-cycles to meet deadlines.

What feature adds that? The borrow checker, lifetimes and ownership are all compile time concepts in Rust.

Re: Should you Rust in embedded yet?

#90

Post by vardump »

atilaneves wrote: post #81
bb88 wrote: post #18

Earlier quoted context omitted.

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones. > you can actually figure out in your head what the assembly will look like I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do. And it's not…

> I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do.

Uh. That's a pretty obvious one.

Sometimes using address generation ports is preferable to ALU ports.

Also 'lea' can load the result in a different register from both operands, 'add' will always need to modify a register.

People have been using 'lea' for calculations since dawn of time, for example:

  shl ebx, 6
  lea edi, [ebx*4 + ebx + 0xa0000]
  add edi, eax
== y * 320 + x + framebuffer address.

This was a common way in DOS days for calculating pixel address in mode 0x13.

Post reply on HN