The Tech Blog

Last week, you would have probably read that the US White House released a report on general guidelines for future software to safeguard from cyberattacks. It has specifically called out coding languages C/C++ for vulnerabilities in memory safety and to move away from it in the future. Let’s discuss what the problem is and why it matters.

Memory safety in programming refers to the practice of preventing memory-related errors and vulnerabilities that can lead to unpredictable behavior of programs running any device out there, from PCs to Phones to IoT devices to satellites. Anything that software can run on can be a potential problem. Memory-related errors can cause a range of issues, from unexpected crashes to hackers exploiting the issue to steal/corrupt your data. Reports estimate that atleast 70% of the security vulnerabilities in the last 30 years have been only due to memory safety issues. Since the majority of the critical code written over the years is in C/C++, it’s a big deal to plug this issue.

C and C++ are languages that are notorious for not being memory-safe because of the way it was initially designed back in the day. Examples would be when a pointer is pointing to a memory location that has been freed or is no longer valid, OR when a program allocates memory but forgets to deallocate it and over time, this can lead to the exhaustion of available memory OR accessing array elements beyond the defined length of the array OR reading from or writing to uninitialized memory. C/C++ compilers don’t check for these errors during compile time. Since these are relatively hard to spot, the testing team reviewing the code might also not find it unless they are very experienced. There are talks about bringing these to C/C++ but I don’t think they can do that without breaking existing legacy stuff.

So what’s the solution? Use newer programming languages like Rust, Go, C#, Java, Python, etc. It’s very hard to cause memory issues with these languages. Over the years you will see people switching for good, but legacy codes will still be a problem as C/C++ still gives you the best performances.

In recent client discussions on FLOPs and the process of selecting embedded SoCs, I found it essential to share some insights here.

FLOPs or Floating Point Operations per second, is a metric used by computing folks to measure how many floating point operations your device can do per second. The larger the FLOPs, the faster the system processes computations. There are variants like GFLOPs, TFLOPs, PFLOPs denoting Giga, Tera, Peta, indicative of higher compute capabilities. Due to marketing pressures, we usually, see the theoretical FLOP numbers being mentioned in datasheets. The practical scenario introduces various factors, such as data access speed, that reduce this value heavily. FLOPs are usually practically calculated by having an equation similar to (a+(b*c)) involving 2 floating point operations of add and multiply called Fused Multiply Add (FMA), where processors with FMA support perform floating-point multiply-add operations in a single fused step.

While FLOPs are a relevant metric their significance in the embedded domain depends on the nature of the applications the embedded system will be running. Higher FLOPs often translate to a larger power budget, a potential deal-breaker for battery-operated systems. Embedded systems often require a balance between performance and power efficiency. Remember that.

Personally, I find CoreMark scoring to be a superior metric for embedded applications. It offers a singular figure per MHz or per mA indicating processing capabilities for power consumed.. I discuss CoreMark in older posts on my website, explaining why it stands out as a benchmark. But Alas, it hasn’t gained widespread traction, and manufacturers seldom include it in datasheets. It will change in the future I am sure.

In essence, the right processor for an embedded application rests on the specific requirements of that application. Just don’t go chasing FLOPs alone.