TIOBE's Language-Popularity Index Sees A New Top 10 Language: Assembly (tiobe.com)

TIOBE's "Programming Community Index" measures the popularity of languages by the number of skilled engineers, courses, and third-party vendors. Their July report indicates that Assembly has become one of the 10 most popular languages: It might come as surprise that the lowest level programming language that exists has re-entered the TIOBE index top 10. Why would anyone write code at such a low level, being far less productive if compared to using any other programming language and being vulnerable to all kinds of programming mistakes? The only reasonable explanation for this is that the number of very small devices that are only able to run assembly code is increasing. Even your toothbrush or coffee machine are running assembly code nowadays. Another reason for adoption is performance. If performance is key, nobody can beat assembly code.
The report also noted that CFML (ColdFusion) jumped from #102 to #66, Maple from #94 to #74, and Tcl from #65 to #48. But Java still remains the #1 most-popular language, with C and C++ still holding the #2 and #3 positions. Over the last five years, C# and Python have risen into the #4 and #5 spots (made possible by PHP's drop to the #6 position) while JavaScript now holds the #7 position (up from #9 in 2011). Visual Basic .NET came in at #8, and Perl at #9.

Comments

Not convinced

[LinuxInDallas]

I've been involved in firmware development for implantable medical devices as well as other devices and it's simply not true that assembly has much use this day in age. Unless you are coding for one of the small memory footprint AVR or PIC devices you are not going to get better results working in assembly.

Compiling toothbrush code with GCC

[Guy Harris]

Here's a electric toothbrush reference design from Texas Instruments.

Here's the MSP430G22x0 microcontroller used in the design.

Here's a list of software tools for that microcontroller. The list includes something called "GCC", which they say is an "Open Source Compiler for MSP Microcontrollers".

Here's a page from Renesas about electric toothbrush designs.

Here's a list of software tools for Renesas processors; they list C compilers for the R8C and RL78 microcontrollers, as mentioned in the previous page.

So don't assume all the code in your toothbrush was written in assembler language; some of it may have been written in C, although some of the low-level library routines might be written in assembler (or an asm in the C code).

Re:Surprise? Why?

[Anonymous Brave Guy]

That hasn't really been true for a long time, unless your hand-written assembly code will reliably outperform a good compiler's generated code.

Hint: It's a reasonably safe bet that it won't, unless you actually are a world-class expert on the subject, such as the people who write those compilers.

Modern CPUs are not the chips your grandpa programmed. They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors that mean what you think will run fast and what will actually run fast may be two wildly different things, even in apparently simple cases.

Whole teams of very smart people spend years reading and understanding thousands of pages of CPU specs so they can write compilers that analyse and optimize code at the speed of those modern CPUs to generate efficient machine code from it. Even if you can beat them on implementing one simple algorithm in isolation because you can spot something the compiler missed, modern high level languages encode so much more programmer intent than raw assembly that you might still lose out overall because you're disrupting larger-scale optimisations.

Re:Surprise? Why?

[Anonymous Coward]

I write compilers for a living, and I came in to say something much like the above.

I have direct experience recoding moderate sized C++ functions in hand-coded assembly. I have been able to beat the C++ compiler, but... not easily, and not without major elbow grease and lots of my time. It's most often not an easy thing to do, because the compiler has sophisticated scheduling and optimization algorithms, and because of the hardware complexity the parent post is talking about. Most programmers weaned on Java don't quite grasp the performance complexity that exists in modern CPUs.

Does it ever make sense to write asm directly? Once in a while, yes, but in the vast majority of cases, optimization time is better spent at the C++ level improving the time complexity of algorithms that dominate the problem space, or perhaps recoding Java into C++. Outside of very specialized and rare circumstances, I don't find reasons to optimize below the C++ level.

There are highly constrained devices where directly coding asm is the way to go, but fewer and fewer all the time.

Re:Surprise? Why?

[K. S. Kyosuke]

In the day of viable superoptimizers or superoptimizer-generated peephole optimizers and viable evolutionary/exploratory/search-based compilers, you should need to know assembly even less than ever before. Remember, the machine can try out new things both faster than you and cheaper than you.

Horsecrap

[Giant Electronic Bra]

You may be right for some VERY small and trivial applications, but sometime in the early 90's optimizing C compilers FAR outstripped hand-coded assembly for any larger project. These days it isn't even a contest. A good optimizing compiler like the Intel C/C++ compiler can crank out code that is anywhere from 3 to 10 times faster than what you can do by hand. I should know, I did PLENTY of Assembly, and worked with some LARGE assembly-language applications back in the 80's. ALL of them were totally rewritten in C before 1995, and I'm talking about RTOS kernels and stuff, things where one clock cycle matters. There may be some few very specific 'inner loop' interrupt handling logic and such that is still written in assembler, mostly because that sort of code is idiosyncratic and can't really be safely optimized, but we're talking a very few lines of code, maybe 500 out of 500k SLOC.

I can buy the idea that there are 'IoC' things out there with extremely minimal processing power, basically little 8 bit devices with a few K bytes of RAM and Khz CPU clocks that you really CANNOT code in an HLL. Of course the amount of code that you write for that thing is obviously also extremely minimal. We're talking "blast this fixed length 802.11 frame out there every 2 seconds with these 12 bytes holding the RAW bit values from the ADC and the 3 discretes to a broadcast address" kind of thing.

Re: Surprise? Why?

[Anonymous Coward]

Take a look at OpenSSL some day cowboy.

Generally the asm paths are at least 3x the speed of the code the best compilers can generate.

When the speed up for using asm on Itanium was 5x was when I realized it was doomed. The compilers were further from human performance than on the older architecture and that wasn't going to improve.