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

Surprise? Why?

[Anonymous Coward]

If you want speed, assembly is the ONLY option.

Re:Surprise? Why?

[drinkypoo]

If you want speed, assembly is the ONLY option.

But virtually all of the optimization happens in virtually none of the code, I always forget the percentages but they are probably made up anyway. You will need some ASM. I think it's more credible that more people are writing some ASM for some parts of some projects. It's not unreasonable to imagine that the ongoing proliferation of embedded doodads would spur that on, but it's a stretch to imagine that it's for devices for which there is nothing but an assembler.

Re:Surprise? Why?

[Anonymous Coward]

Nonsense. Everyone knows that C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

Re:Surprise? Why?

[BarbaraHudson]

Yeah, right ... NOT!

Re:Surprise? Why?

[Darinbob]

There's more than one reason to want optimization. There's optimizing for speed in a full algorithm, in which case assembler isn't that important. But optimizing for speed in localized locations can be very important. Ie, the faster your interrupt handlers are the better I/O throughput you can get, or faster context switches, etc. If you're programming on a DSP for instance, you almost always want the best speed and that often means assembler or assembler wrapped inside of macros or special directives. There's also optimization for size, and occasionally assembler helps there as well to cram in as much as you can in the limited space.

And of course you need to *know* assembler even if you don't write it. It's how you decode core dumps, figure out what your code is doing, and lets you treat the machine as more than a black box (I've seen people with efficient algorithms that weren't so fast because they didn't understand what was fast or slow under the hood).

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?

[WarJolt]

People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.

If you're writing intel code you'll probably see better speedup using c++17 parallel policies or some other parallelization framework, but sometimes it is necessary to optimize small segments of code. Premature optimization is the root of all evil and effective use of templates and metaprogramming can go a long way without much effort. Embedded devices should be treated to same way. Write a high level implementation in the highest level language available to you and hand optimize only when necessary.

I've compared c++ stl implementation of algorithms to c implementations and my c++ almost always runs faster with significantly less code. Small programs that calculate trivial results are always faster in low level languages, but real programs need complicated structures and its almost always infeasible to hand optimize those effectively.

Re:Surprise? Why?

[Anonymous Coward]

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.

I have only done a small amount of assembly, but I think where it might win is simply accessing functionality in the CPU that is not as easy to get to other ways. For instance, if your compiler isn't using all the nifty tricks possible in your cpu, and one of them applies really well to the algorithm your using, then maybe an assembly language function for that one key bit makes sense, provided tying your code that closely to a particular feature or features in a CPU is okay to do... For instance, just creating a function call in asm that executes rdrand is actually useful. Similarly if you could somehow figure out how to get your algorithm to run without having to access main memory nearly as often, well maybe you have something there, though again, unless your using functionality your compiler doesn't know how to use the odds probably aren't great.

Actually here is a possible valid use for assembly. Certain parts of code may deal with manipulating encryption keys somewhat securely. Some hand coding there may result in code that can be proven to meet certain criteria, and since it is hand coded, you know that that code will always meet those criteria, even if the compiler changes. For most things though, everything I've read seems to indicate trying to win by going with assembly is a very unlikely endeavor.

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.

Re: Surprise? Why?

[K. S. Kyosuke]

One might argue that the C code was bad in the first place. Unless the templated C++ code did vast rearrangements of data structures (how?), DataDraw-like approaches are still likely to beat it. Having said that, both C++ and C don't really seem like a really good vehicle for implementing the techniques that could search for the fastest machine code for particular subtask.

Re: Surprise? Why?

[Boronx]

There are a couple of reasons to optimize early.

Design of your program may change depending on maximum capability. It's better to change a design earlier in development.

Faster run times can improve testing and debug cycles.

Re:Surprise? Why?

[Boronx]

There are a lot of processors out there that aren't complicated. On an 8 bit microcontroller with an instruction set size of only a few dozen, it's not hard to beat compiled code.

Re:Surprise? Why?

[Opportunist]

No. Yes. No. Uh... that really depends.

On a modern desktop CPU, no chance. gcc optimizes in ways you wouldn't even dream of. Even Visual C++ produces decently optimized code. Usually, writing ASM yourself you can't come close to the optimization level that modern compilers achieve.

Except Atmel's very own compiler. That's the maybe WORST kind of rubbish I have ever seen. Here you can actually gain a LOT of performance and code size by hand craftin ASM code. Which says something considering that, unlike desktop PCs, AVR ICs are very limited in space and processing speed and if there should be any compiler that takes optimization seriously, it's that one.

Fortunately gcc is quite capable of optimizing well even for AVR...

Re:Surprise? Why?

[gweihir]

Bullshit. A good C-compiler will do as well or better in most cases. For the rare case where it does not, embed assembly for the critical parts. You may also need embedded assembly in drivers, where hardware has to be accessed just right in order to work or work fast.

Re:Surprise? Why?

[Opportunist]

Counter-intuitive as it may seem at first, the smaller your instruction set, the higher the chance that the compiler is actually better at optimizing than you are, unless you have a LOT of experience writing and optimizing assembler code. Mostly because the smaller the set, the longer the code gets and the more you have to take into account certain side effects from instructions. I spent quite a few hours puzzling why the compiler would completely rearrange the instructions only to notice that it gained a bit of an advantage from creative pipeline restructuring and carefully manipulating certain jumps.

The only area where humans outperform compilers reliably is conditional jumps. Because humans can usually more readily tell from the intended program flow which branch is more likely to be executed and can optimize the programs in that way. Hand that information to the compiler and I hold any bet that it will outperform you any day.

Re: Surprise? Why?

[gweihir]

And there are more good reasons to not do it except in special cases. The primary one is that it makes coding much more expensive, mostly via increased effort in debugging.

Re:Surprise? Why?

[Pseudonym]

There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics because a typical assembly programmer can use a compiler but a typical high-level-language programmer can't use an assembler.

An assembly programmer can use a profiler to work out where the problems are, inspect the output of the compiler, see what's wrong with it, and fix it using assembly. (Today we might include intrinsics as a potential fix, of course.) Assembly programmers write faster code because they can also use a compiler.

Re:Surprise? Why?

[gweihir]

If you do not know assembly, you cannot be a really good coder and you cannot even understand how common attacks on code work these days or why some things run much slower than others. That said, actually coding in assembly is something you only do when there are very good reasons to and mostly as assembly embedded in C.

Re:Surprise? Why?

[gweihir]

If you are on an 8 Bit MCU, speed is not that critical, or you would use a larger and faster MCU.

Re:Surprise? Why?

[Rockoon]

They are full of caches, pipelines, predictive execution, parallel operations, and numerous other confounding factors

You are using all the same arguments C/C++ programmers used in 1995 but if the discussions wasnt about assembly language but instead the discussion was a comparison of compilers from 1995 with compilers from 2015 you would be telling us how terrible those 1995 compilers were at optimization even then.

The fact is that it doesnt require an expert to beat a compiler at optimization. The fact is that your idea of an "average assembly language programmer" is actually a terrible assembly language programmer. When you dont consider someone that learned C/C++ a month ago an average C/C++ programmer, why do you then consider someone thats literally never actually taken assembly serious as the benchmark average?

..and if you are "confounded" by caches, pipelines, superscaler techniques, and so on ("cause surprise or confusion in (someone), especially by acting against their expectations.") then its because you are ignorant of the architecture. Your ignorance doesnt define reality.

Recently a programmer undertook the task of converting the strongest open source chess engine (stockfish) to 80x86 assembly language. He still has done no optimization. He has literally just done a straight simple conversion and its already 10%...20% faster and is now easily beating the C++ compiler version in tournaments.

..and notice how its now 10% faster... or 20% faster... there is a range because it depends which gcc compiler version is used (older versions produce better code.) If gcc has such a large variance in performance, if newer versions are slower, then what are we to think of the veracity of your claims? I'll tell you what: they arent veracious claims. They are wishful thinking.

Re:Surprise? Why?

[BlackHawk-666]

No it's not. C is also an option, given a good optimising compiler.

Re:Surprise? Why?

[Pseudonym]

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

I apologise in advance for the following rant. It may not be fair to direct it at you personally, but I'm going to do it anyway.

There is a trend happening in modern C-family compilers where they have decided to go full language-lawyer on aliasing rules. It's getting much, much easier to write code which looks sane and has worked for 20 years, but compiles to code which subtly does what you don't expect on the most recent compilers.

Now this isn't entirely your fault, because C-family language standards are severely obsolete and kind of stupid in this respect. The aliasing rules date from an era when CPUs were much slower than they are today. I do a lot of scientific-type high performance code, and I don't think I've seen a performance issue in the last decade that can be blamed on pointer aliasing, despite the C-family committees still act as if this is the most insidious performance problem in the world. But I have been bitten several times by compilers generating code that may be technically correct (the best kind of correct!) but clearly not what the programmer intended.

The standards are full of these nasal demons, where you shouldn't go there just in case the compiler decides in its wisdom to optimise that code in a certain way. Is it so much to ask that once in a while we might get a performance guarantee? Something which says "If you write the code this way, this will definitely happen". Hell, Scheme programmers get a guarantee that tail call optimisation always happens. We don't even get a guarantee on the empty base optimisation!

We may see more assembly in the years to come, not because it's faster, but because assembly has "do what I say" semantics in a way that C and C++ do not.

Re:Surprise? Why?

[BlackHawk-666]

Is that the CPU and instruction set we are all using, or is that some specious reference to a bygone era with no actual current value?

Re:Surprise? Why?

[BlackHawk-666]

Spoken like a twat that hasn't got any metrics to back up his rhetoric.

Re:Surprise? Why?

[K. S. Kyosuke]

Yes, knowing assembly and actually writing it for no good reason are two entirely different things. I was arguing against the latter.

Re:Surprise? Why?

[gweihir]

I fully agree that writing assembler without a very good reason is not a good idea today.

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.

 

Re:Surprise? Why?

[chipschap]

I used to write assembler. But that was in the days of very limited machine memory, when saving a couple of bytes would matter. It was also in a day when compilers put out relatively inefficient code. Programming, say, I/O, at the assembly level would likely produce code orders of magnitude faster than compiled code that used repeated calls to I/O libraries.

But today there's plenty of memory in most computers, and compilers are really good. So I only see two reasons to write assembler. One is to deal with small "things" that may still have very limited memory and processor capability. The other is in analysis, such as analysis of malware, artful decompiling, and good old-fashioned hacking and cracking (by Good Guys (TM) only, of course). The latter may not be so much writing assembler (unless you're crafting binary patches) as in understanding assembler.

Re:Surprise? Why?

[Anonymous Coward]

a throw in for asm. yes, aliasing is a huge problem.

but think for a moment about calling convention overhead. at a call boundary the compiler has to thread through the callee/caller save conventions,
manipulate the base frame, excessively to store things back into the stack frame of the local closure, wend things back so that the caller
is not disturbed, etc.

all so that functions behave in a very unsuprising way, so that we can compose them after the fact under the purview of the linker

if you have alot of small functions, all those framing overhead and moves add up, alot

so sure, hand coded assembly just to give craftsmen their due, but shop hobbling the compiler for no good reason

Re: Surprise? Why?

[Anonymous Coward]

Double plus on the mention of templates. A well-done template or derived class eradicates an if ... and this if is causing cache misses down the road, which are the worst thing to performance there is on modern day computers. Even a virtual call is better than a branch of which the compiler cannot really deduce the outcome.

The if is the number one sign of a lowby programmer.

Re:Surprise? Why?

[tepples]

the smaller your instruction set, the higher the chance that the compiler is actually better at optimizing than you are

Unless the authors of the only compiler for your ISA maintain it as a hobby and aren't interested enough in optimization to quit their day jobs. Case in point: cc65.

Re: Surprise? Why?

[Darinbob]

Basically the code and vars won't fit in the chip I have at the moment without finding weird ways to save space. So there are times when changing something in assembler can save a couple hundred bytes. There's also parts of the code even more constrained in size, like a bootloader that has to fit in 4k, so optimizing there is worth it.

Re: Surprise? Why?

[Anonymous Coward]

FWIW, when I write assembly, I routinely beat GCC in execution speed by 30% without even trying.

And yes, it is possible to write modular, well-structured assembly language programs. Stick to calling conventions, make local variables truly local, implement objects when necessary. And document everything. Writing in assembly no more removes the need for good design than writing in C++; though I must admit, I've seen many more poorly architected C++ and Java programs than assembly programs.

Assembly teaches you to think about program structure and efficient use of resources. To write maintainable assembly programs, you MUST think about architecture. You have to be able to manage both high level and low level details *in the same context*. What hamstrings a lot of HLL programmers is they believe that HLL programs obviate the necessity of good design, and go on to write horribly unmaintainable code because HLLs encourage both laziness of thought and practice.

Assembly requires discipline, that one acquired, will make one a good programmer in any language. The same is not true of C++ or Java, where many a programmer spend years writing awful code before really learning how to use it well. And some coast by without ever learning how the underlying mechanisms are implemented, that memory is not -GASP!- unlimited, that CPU time does matter, and the problems of resource allocation and release do not simply "go away" because the compiler implemented new (think about what happens to open sockets, queues, and the like when the destructor is called).

Re:Surprise? Why?

[Rockoon]

Spoken like a twat that hasn't got any metrics to back up his rhetoric.

You are right. I dont have metrics. I just have binaries.

C++ version of stockfish
80x86 asm version of stockfish

One of these is faster. I'll let you decide what "metric" to use.

Re:Surprise? Why?

[Anonymous Coward]

While I'll admit that compilers have come a long way, the problem isn't just one of optimization. Assembly programmers can choose algorithms unavailable to the HLL programmer. Jump tables are a good example - in the worst case, a select statement incurs no more complexity than a string of if-else blocks, but an assembly programmer who knows that speed is of the essence can choose between conditional evaluation and a jump table. You know, an algorithm that executes in constant time regardless of size, rather than one which executes in linear time dependent on size. Such an algorithm will *NEVER* require additional optimization, regardless of how program flow and data changes.

The compiler - to be correct - must implement faithfully what the programmer wrote, not make guesses at what he intended. Since HLLs are by definition a subset of the possibilities of the assembly programmer, they can never beat both the general case and the specific case - they must be optimized for one or the other, and it's usually the specific case which loses. In the worst case scenario, an assembly programmer could simply look at the compiler output and learn how to do it as well as the compiler.

In most cases, though, assembly programmers won't simply implement it with fewer instructions, but rather will use algorithms which take advantage of the hardware. You know, things like using a DMA transfer rather than string instructions. Or string instructions when DMA isn't available. Or build the code and data in one cache line, so that the CPU already has the local, static variable fetched when the function is called, rather than having to fetch it from who-knows-where in main memory. And the odds that the ENTIRE PROGRAM fit into the cache are still quite good these days - 16k (hello Pentium!) is still a large amount of code for an assembly programmer.

It's not so much that compilers aren't good at what they do, but that they are constrained in what they can do by the requirements of the HLL. I've never seen a C compiler that didn't use a stack on x86 for function call nesting, even though the language could be implemented without it. There are conditions for which an inline function can't be inlined by the compiler, and it's doubtful that the majority of C coders know them. There are also conditions - like function call eliding - that can create problems when a write must be performed (like erasing encryption keys from the stack).

Re:Surprise? Why?

[Rockoon]

And this guy specializes in testing the strength of stockfish as it evolves:

http://spcc.beepworld.de/

Note how he included a june build of asmfish, and that asmfish is leading even against july builds of stockfish.

Which "metric" should we use?

Nodes per second? asmfish is faster than stockfish.
Time to depth? asmfish is better than stockfish.
Playing strength? asmfish is better than stockfish.

I wonder what metric this guy is going to want to use that retains his wishful thinking of C++ supremacy. Maybe the number of lines of code?

Re: Surprise? Why?

[hackwrench]

I have a hard time understanding the benefits of after the return restoring the stack over during/before the return. When you do it that way you have to write stack resetting code every time you return from the call instead of just once. My best guess was that it has some benefit for procedures that could accept a variable number of parameters. The former was called "c" passing and the latter "pascal". Somehow the pascal term got changed to system if I'm looking at #defs correctly. Maybe with a few underscores thrown in. Then there's the left-to-right/right-to-left mess.

Re: Surprise? Why?

[Anonymous Coward]

Comments like these are why I still love slashdot.

Re:Surprise? Why?

[Anonymous Coward]

"Nifty CPU tricks" - This is why you use the newest Intel compiler and learn to use its flags.

Re:Surprise? Why?

[Anonymous Brave Guy]

GCC has never been a very useful benchmark for compiler performance in my experience. Even a decade ago, when I used to work on a lot of very performance-focused mathematical code that was compiled on many different platforms, Visual C++ would generate code that often ran twice as fast as anything g++ would produce on Windows, and if you looked at what the Intel C++ compiler could do it was much better still.

It's also worth remembering that C++ is still quite low level on the programming language spectrum, and in terms of expressive power and showing programmer intent, it isn't exactly the most promising choice; potential aliasing alone prevents all kinds of otherwise useful optimisations, for example. There are much more powerful optimisation possibilities for higher level languages with more expressive semantics, some of which will already dramatically outperform a naive assembly equivalent with today's real world compilers. As CPUs get more complicated and compilers for higher level languages get better, the scales are only going to tip further in that direction.

Re: Surprise? Why?

[Anonymous Coward]

I've had a long career in the embedded space and have never used an intel processor other than an ethernet controller. About a 30/70 asm/c(c++) mix.

Re:Surprise? Why?

[geezer nerd]

Counter-intuitive? Maybe, but what you are saying here is largely the argument used 50+ years ago in developing RISC (Reduced Instruction Set Computers), the technology which led to the first so-called supercomputers capable of sustained operation at megaflop+ speeds. Although I have not kept up with today's chip architectures all that carefully, I am sure that many of the characteristics of RISC continue to be present.

Re:Surprise? Why?

[Anonymous Coward]

There are way more 8-bit processors out there than intel beasts, you dirty, ignorant nigger.

Re:Surprise? Why?

[thinkwaitfast]

Modern cpu does not necessarily mean big complex processors. In embedded sometimes very small processors with simple instruction sets are used to save power and money. Sometimes a simple analog circuit can be done simpler in digital, but you may not need more than 6 bytes of ram or any more instructions than or, not, shl, mul. If that is the extent of what your cpu does, why would anyone bother writing an optimizing compiler for it?

Re:Surprise? Why?

[thinkwaitfast]

I think most case statements switch from else-it to jump tables past about 5-6 cases.

Re:Surprise? Why?

[thinkwaitfast]

In 2008, there were some 30 embedded microprocessors per person in developed countries (PDF). Most of those don't have plenty of memory. There is a whole entire world out there that you are likely unaware of.

Re:Surprise? Why?

[Anonymous Brave Guy]

In embedded sometimes very small processors with simple instruction sets are used to save power and money.

Sometimes, yes. As you say, in addition to assembly programming being simpler on those platforms, compilers are often much less sophisticated in their optimisations as well, so going with assembly is a double-win.

That said, in an era when you can build a complete Raspberry Pi with a decent ARM chip for a few dollars and when mainstream CPUs are a lot more power-efficient than they were even just a few years ago, using very low-end CPUs is a lot less attractive than it used to be even in the embedded space.

Re:Surprise? Why?

[thinkwaitfast]

There are probably hundreds of different CPU's out there. Many for which specs have never been published. Everyone here has a PC class mentality, but in the real world, there are dozens of very tiny and primitive processors doing simple tasks that you never see. Decoding a front panel to a tv for instance. It may be less expensive to create your own proprietary cpu and have three million made at $0.04 each than to add the circuitry necessary for the main processor in your tv to handle it. Nobody is going to bother writing an optimizing C compiler for a processor that has six instructions and 16 bytes of memory. I've worked on many similar systems that would not most of the C language.

Re:Surprise? Why?

[jhol13]

There are a lot of cases where the compiler will pick it wrong, especially in embedded world.
Maybe compiler assumes code is run from ram although it is run from flash, meaning different code is a lot faster.

Then there are cases which the compiler cannot even handle, like cache cleanup and memory barriers - there is no way the compiler can know the peculiarities of your (custom) system. Same with task swap and atomic operations. You might be able to write those with C intrinsics, but even then you must know what code the compiler will create (i.e. not let optimizer reorder operations over a memory barrier - far from trivial).

The compiler support for those cases hasn't really improved in last ten years or so, actually due to new aggressive optimizations it could be said it is worse.

Re: Surprise? Why?

[Anonymous Coward]

Do you have something against black people? Why?

Re:Surprise? Why?

[Tablizer]

The only area where humans outperform compilers reliably is conditional jumps. Because humans can usually more readily tell from the intended program flow which branch is more likely

Why can't hints be added to compiled languages to indicate the most common route? For example, special comments? Oracle SQL has a feature where a plus sign in comments indicates it's an optimization hint: /*+ ... */

Re:Surprise? Why?

[thinkwaitfast]

even in the embedded space.

Completely application dependent. What if your requirements are to operate 6 months on a single AA battery and the whole application is to shift out a 16byte sequence? There are about 20-50x more systems with requirements like this in the world than those that would require an atmel or arm chip. I worked on a system once that had such requirements because it was cheaper than a couple of TTL parts. This was a tiny subsystem on a larger computer board with real processors and RAM.

Re:Surprise? Why?

[thinkwaitfast]

And remember 15cents spread out over 30 million widgets is $5million.

Re: Surprise? Why?

[Anonymous Coward]

How dare you. Java is the best option. We all know this. WORA baby! Get with the program. Install a jre first though or your machine won't know what it is. And a virus scanner. Block crital ports. Always upgrade quickly. Set your memory recovery options carefully. Don't allocate too much memory to the stack. Reboot if too much processing is done to free up lockes files. Worship Oracle. Join a 1 minute hate club (the two minute hate is out of date). Report to room 101 if you do not comply. Welcome to MiniProg.

Re: Surprise? Why?

[Anonymous Coward]

It's usually considered best practice to do allocation and deallocation close to each other, and there is no particular reason for stack to be different.
Also you don't "reset" the stack after each function call, what would be the point. You just track the current offset between the stack pointer and the actual stack.
If the called function messes with the stack pointer, a tight loop with a function call suddenly has a significant overhead because you need to adjust the stack pointer every time you call that function.
The "Pascal" calling convention has more differences, like argument order, that are a bigger issue for var-arg functions.

Re: Surprise? Why?

[Shinobi]

One benefit of hard resetting a stack, register or even a variable after each use is that it is a step towards making your code more deterministic, by setting it to a known safe state.

For some of the driver code I develop, the ability to do that in a strict manner, without a compiler overriding my design, is why I use some assembler.

Re: Surprise? Why?

[Anonymous Coward]

Which compiler? Have you actually checked what shit code compilers produce?
Maybe you only ever look at medium-complex, computational code sections that compilers are heavily optimized for?
Even today, try declaring a array of classes with maybe 10 byte-sized variables that the constructor initializes to 0 (with inlineable constructor of course) and cringe when you see the moronic compiler like gcc do it with a loop over the array and 10 individual movs inside that loop!
To this day, EVERY compiler REGULARLY generates code that even the most mediocre programmers can speed up > 5x.
Yes, compilers nowadays can also create great code. But they still completely fail at doing so RELIABLY, and when they fail, they fail HARD.

Re:Surprise? Why?

[Anonymous Coward]

This is bullshit. I look at the output of AVR C compilers and it is utterly woeful compared to the stuff I write by hand. What it comes down to is that the C compiler has to, by design, comply with some ABI, so that any function can be called by any other (even though it's not). This easily bloats up the program text to the point where a design that is trivial to fit in a small AVR in Assembler just will not fit if you attempt to write it in C. In assembler you can make inter-procedure optimisations like exclusive use of registers in a callable or callee so you don't have to save them, writing non-structured "word" style procedures like is frequent in Forth, etc. I might believe you when I see a compiler that can do global compilation rather than rigidly adhering to some ABI spec, but until I do, I'm going to call bullshit on everything you say.

Re: Surprise? Why?

[johannesg]

I'm not surprised that compiler technology never caught up with itanium. The volume was never there to allow the kind of investment that made the x86 compilers so amazing.

Re: Surprise? Why?

[johannesg]

Assembly weeds out the less competent programmers early after they realize they simply aren't up to the task. In other languages they can stick around for longer and might eventually learn. So what is to be preferred: that they learn eventually, or simply leave the field?

As for what happens 'when the destructor is called', it will clean up the sockets and queues and the like; that's what they are for. 'delete' is not just for deallocating memory, it is for deallocating all controlled resources. It's possibly the most fundamental building block of C++; I'm a little surprised you don't know this considering how much of an opinion you seem to have on higher level languages...

Re:Surprise? Why?

[Megol]

You seem to be experienced in being a twat without anything to back up his rant...

Re:Surprise? Why?

[thegarbz]

The only area where humans outperform compilers reliably is conditional jumps.

The problem here is that in software a conditional jump IS what makes it useful. Software will be full of it and this is exactly the kind of thing that can lead someone to out-optimising a compiler.

A compiler can generate perfect code for pretty much every bitwise operation. It can even be told to do it in the smallest size (prioritise looping) or fastest speed (prioritise linear execution). Beating a compiler in doing mathematics such as non binary division is also an incredible feat. But beating a compiler using a clever set of conditionals is actually quite trivial.

That said on a simple system people don't realise how much control they have on the assembly generated. e.g. do-while and while-do for instance generate different code. Vendors write hole manuals on how their compiler handles these scenarios allowing you to optimise your assembly in your higher level language.

Re:Surprise? Why?

[Megol]

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.

Compiler writers aren't generally skilled in assembly language programming.

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.

Have you ever written any assembly code? Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.
Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.

Now if we'd be talking about a strongly skewed architecture like a non-interlocked VLIW your statement would be more correct _but_ not true. A skilled assembly coder would still generate better code than a compiler however with a lot of effort.

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.

The only advantages of high level languages are portability and faster programming. But the disadvantage is a worse interface to the actual execution hardware - and that is a huge disadvantage.

Re:Surprise? Why?

[Anonymous Coward]

I think it's a bit different than that. There are things well-tuned compilers are better at, like scheduling, and there are things humans are better at, like exploiting hard-to-generalise opportunities. I don't think the instruction set size has much to do with it. I think you can find examples that favour either humans or compilers of both large and small ISA variety.

Rather, you want a close match between the instructions provided and the sort of thing the writer --compiler or human-- needs to be done. Hidden complexity makes this match harder, but the kind of the complexity might favour either human or compiler. Point in case, for the J1 FORTH CPU there's really nothing to be done for either because the impedance match between ISA and higher level language is so close. This means that most code will be automatically close to optimal.

Re:Surprise? Why?

[Anonymous Coward]

Hell, Scheme programmers get a guarantee that tail call optimisation always happens.

The problem with that is that it makes an assumption about the processors stack and how it works.
A guarantee that tail call optimisation always happens has a tradeoff that it doesn't for more obscure architectures.

ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.
(With the possible exception of Quake 1 bytecode, for some reason every obscure device out there gets a Quake 1 port.)

Re:Surprise? Why?

[Tough Love]

There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics...

Dozens of posts so far and all missing the central point: in terms of determining popularity, tiobe's methodology is junk. People search when they have questions. Sure, more people have questions if more people are using a given language, but this is trumped by obscurity and steep learning curve. Really, there is little in the technology world more obscure or harder to master than machine level coding. If a language is well structured then you just go straight to the web resources, the many excellent C++ sites for example. When nothing makes sense and you don't know where to start, you ask the search engine. Therefore poorly documented and really hard to use languages tend to look excessively "popular" to tiobe. Nonsense.

Now, what really worries me... those people searching for answers about assembly language... they have no idea what they are in for, and what a hazard they are going to be if they actually try to apply the superficial level of knowledge you get from web answers to writing assembly level code of any complexity.

Re:Surprise? Why?

[Anonymous Coward]

That exists. __builtin_expect for gcc, for MSVC it is assuming that the if is taken, and then there is the whole profile-guided optimization. So I don't think this a reasonable argument against compilers at all (there are others, like "compilers suck" though).

Re:Surprise? Why?

[Anonymous Coward]

gcc can do those optimizations with it's whole-program optimization (or LTO in newer ones). If you didn't use that, it's no wonder you got horrible code.
However even with it, there are specific things that cause compilers to produce unacceptably bad code, so you still have the job of finding those places and rewrite them in assembler (or hack the C code until the compiler finally gets a sensible way to compile it).

Re: Surprise? Why?

[Anonymous Coward]

wow sign of a lazy highby

if you knew anything about low level you would understand how to code efficiently without all that shit.

fucking modern programmers, with way too much memory and cycles to waste, think they understand what efficient coding really is, dumb as a box of rocks.

try coding a complex alogo on a processor with 128bytes of ram and 1k program storage, you might learn something.

games were originally coded to the metal for speed and space restrictions, modern games are lazily programmed with masses of memory and overpowered cpus

Re:Surprise? Why?

[Anonymous Brave Guy]

Compiler writers aren't generally skilled in assembly language programming.

To be fair, neither are most people writing assembly language. Most people I've worked with in this area certainly didn't have an exhaustive knowledge of all the available opcodes and their detailed performance characteristics on every processor architecture we targeted. I'll be the first to admit that I didn't.

However, some of the best assembly programmers I've known have been working on compilers. It makes sense to hire those people to work on code generators used by millions rather than to hand craft assembly for individual projects.

Have you ever written any assembly code?

Yes, professionally, for some years, on several different architectures, and in performance-sensitive applications. These days I read assembly a lot more than I write it, for exactly the reasons we're discussing here.

Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.

Perhaps, but Pentium 4 was hardly the same as today's major CPUs from the likes of Intel and ARM. It's not as if writing an XOR to zero a register is the most tricky thing to get right any more.

Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.

The thing is, though, that good compilers for high level languages can look at much larger areas of the code and systematically optimise them, thus making better use of finite resources like cache capacity.

Will your hypothetical assembly programmer consistently rewrite their functions to perform the appropriate level of inlining and fusion effects based on context? Modern compilers for some high-level languages already do.

Will your hypothetical assembly programmer rewrite their entire function a different way with more efficient register allocation if the underlying algorithm changes? (Granted this one is less relevant these days if we really are talking about a relatively high-end CPU with plenty of registers available anyway, but not all CPUs have that luxury.)

Will your hypothetical assembly programmer rewrite an entire hierarchy of functions a different way to avoid both blowing the FPU register stack and spilling unnecessarily?

Will your hypothetical assembly programmer detect implicit parallelism in their algorithms and restructure them to use parallel low-level operations (as in SIMD) and/or multiple threads for better performance? There's a lot of research going on in these kinds of areas for building better HLL compilers, too.

The only advantages of high level languages are portability and faster programming.

You missed the crucial ones that give compilers a natural advantage in the long term: they can analyse much larger parts of a program together, even a whole codebase; they can do it with extra semantic information about actual programmer intent to guide them; and they can do it consistently and quickly. Those compilers can apply optimisation and code generation strategies at much broader levels than any manual assembly coding ever could.

How can manual assembly hope to match the kinds of large-scale optimisations performed by modern HLL compilers across functions? You'd have to write a new unified assembly function for every combination you needed. Obviously that is possible in theory and anything a HLL compiler can do can be done in assembly as well, but the amount of work required is already prohibitive in some cases and will only become more so with time.

Re:Surprise? Why?

[Anonymous Brave Guy]

True enough, and I agree it could sometimes be relevant. But looking at it the other way around, $5M spread out over 30 million widgets is only a few cents per widget, so unless your widgets are extremely price sensitive and your requirements extremely simple, this is unlikely to be a deciding factor.

I work with clients who develop various embedded systems, and I haven't actually seen a real world example of using a very simple, very cheap CPU in this way for probably more than decade now. YMMV depending on your industry, of course.

Re:Surprise? Why?

[Anonymous Brave Guy]

Completely application dependent. What if your requirements are to operate 6 months on a single AA battery and the whole application is to shift out a 16byte sequence? There are about 20-50x more systems with requirements like this in the world than those that would require an atmel or arm chip.

That's quite a strong claim to make without any supporting data. I do a fair bit of work in the embedded space, as do many of my colleagues, and the overwhelming majority of that work in recent years has been with more powerful CPUs. Obviously our experience might not be representative of the wider industry, but we'd have to be extreme outliers if your figure is correct there.

That is not to say there isn't also a need for much simpler devices. However, in those cases you're probably programming them in assembly because that's all you've got and your logic is almost trivial. You're probably not writing assembly just because it's faster, which was the original claim in this discussion.

Re:Surprise? Why?

[Anonymous Brave Guy]

I might believe you when I see a compiler that can do global compilation rather than rigidly adhering to some ABI spec, but until I do, I'm going to call bullshit on everything you say.

Good mainstream compilers have been doing that for well over a decade, and the best ones are much better at it than any human will ever be.

Re:Surprise? Why?

[dunkelfalke]

RISC made sense when silicon real estate has been a premium. Nowadays not so much, hence modern RISC chips have way more instructions than CISC CPUs. Also complex instructions make more sense nowadays, because bandwidth is premium now.

Re:Surprise? Why?

[Pseudonym]

The problem with that is that it makes an assumption about the processors stack and how it works.

Not exactly. If your language needs to support cactus-stack-structured lexical closures anyway, it can be worth not implementing your activation stack in terms of the CPU's stack. Notably, Appel's original ML implementation didn't bother with a traditional stack and just allocated fragments on the heap.

ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.

I see you haven't been bitten by this yet. Trust me, when your old code compiles on every architecture you can think of EXCEPT for x86-64, you'll get just a little bit upset too.

Re: Surprise? Why?

[Bengie]

You have to be able to manage both high level and low level details *in the same context*

I code in C#, while I don't code in ASM I have respect for it and have done a lot of reading on it when I was around 7 and have read about modern CPU architectures and cycle latencies and cycle throughputs of different instructions. I have also read about how C#'s GC works, how objects work(More than 128 bytes for an empty object), how interfaces are work(method indirection can be O(1) when you have one implementing class, but O(N) when you have many and they're being used), casting for inheritance (casting child to parent is pretty much free but casting parent to child is expensive, like hundreds of cycles), method parameters work (large structures or too many parameters cause an object to be allocated on the heap that holes the parameters, same with method return types if they're too large).

I can many times jump into some other programmer's code and make it a few factors faster. It some cases, orders of magnitude. My pet peeve is that most people think of performance as an afterthought because "don't preemptively optimize", but they apply this to their architecture. A high performing architecture needs to be designed from the beginning, and this also requires being able to mix high and low level details, even before the low level details are fleshed out.

Re:Surprise? Why?

[Kindaian]

Why not for the pleasure of coding against the processor directly?

Re:Surprise? Why?

[angel'o'sphere]

If you do not know assembly, you cannot be a really good coder
That is bollocks.
Assembly only helps you in doing: assembly. On the machine you know how it works.
It does not help you at all to program Pascal, BASIC, Perl, Java or any .Net.

To learn why your Java program sucks you need to know O calculus and the differences of algorithms and approaches, and: how the Java Virtual Machine works. Oh, just because it is virtual it is not real?

Of you can mot graps how a processor/computer works until you have learned how to programm it with assembly: you lack serious abstraction skills. Probably the reason why you ditch high levle languages and believe knowing assembly makes you superior.

Re: Surprise? Why?

[Anonymous Coward]

While I do generically agree with you, it seems (and its obvious by the 2nd paragraph) you're talking about modern x86 assembly. OOO execution in x86 makes a pain in the ass for manual optimization, but this is not the case in many many embedded/microcontroller systems. You'd be surprised (even in x86) by the amount of garbage that a compiler generates.
And x86 is basically a ISA that covers many, many families. Manually optimizing for i386/i486 is fairly trivial, and you do a better job than the compiler in specific use cases. Pentium/PPro/MMx is a bit more complex, and your mileage may vary. Manually optimizing for P4? Which one :D? Its a friggin pain in the ass. The compiler will probably run laps around your implementation. But if you go further back in time, stuff like unrolling integer multiplications into bit rotations for specific cases (which are not obvious at all for the compiler, except some obvious cases) is a huge improvement. That's the kind of limitations you whave with most not-so-powerful microcontrollers today.

Re:Surprise? Why?

[angel'o'sphere]

Prominent 8bit processors like 8080/8086/8088 variations and Z80: are complicated
6502/65c816, 68008, 6809: thise are easy as they are much more orthogonal in design.

Re:Surprise? Why?

[angel'o'sphere]

8086 is a very old processor.
A compiler hardly can do any optimizations on it.

Why you think that is also true for an i5 or i7 or SPARC or a MIPS is beyond me.

Re:Surprise? Why?

[chipschap]

Yes, I am aware, these are the "small" things I mentioned in my post. Perhaps my wording de-emphasized them unintentionally.

Re: Surprise? Why?

[TheRaven64]

For what it's worth, 30% on a modern x86 is noise. You'll get that difference from very small changes. We recently were writing some assembly code to benchmark the cost of atomic ops. A simple loop that did nothing took 2.5 times as long to execute as a loop that had an extra add in the loop - the simple version hit a pathological case in register rename, which we fixed by adding an instruction zeroing a register and marking it as dead. There was a paper at ASPLOS two years ago that showed that you get a 30% delta on most programs from randomised code layouts just from different cache interaction.

Re: Surprise? Why?

[TheRaven64]

Resetting the stack is just an add to the stack pointer. If you're using any stack space in the callee, then you're doing that anyway and so it's just a different immediate value in the instruction. If you're calling anything else, then you're saving a frame pointer and so it's a cheap register-register move (basically free on a machine that does register renaming).

Re: Surprise? Why?

[hackwrench]

I'm sorry I wasn't clear. I call moving the stack pointer to a specific known point as opposed to pushing and popping, "resetting the stack". The return has to modify the stack when it pops the return address to the calling program. so your statement about needing to adjust the stack pointer every time you call that function makes no sense as the return instruction has a parameter for adjusting the stack in addition to the amount necessary for the call. I touched on argument/parameter order, but I didn't link it strongly to the pascal keyword. I also think that the space saved by using an instruction once at the end of the procedure as opposed to an instruction after each and every return from a procedure a particular reason.

Re:Surprise? Why?

[TheRaven64]

If the function is used from another compilation unit, then you have to do that anyway (or, at least, document the calling convention and make sure that every other call site uses it). If it isn't, then most compilers will mark it as not needing to follow the public ABI and will move to a different calling convention. Some (Pro64 and derivatives, and there's a GSoC project for LLVM this year) will do inter-procedural register allocation on these functions and try to define a custom calling convention where things that the callers want to keep live are callee-save. That's very hard to do manually for anything that has multiple callers (and if it only has one caller, any modern compiler will inline it and you'll have no call overhead).

Re:Surprise? Why?

[TheRaven64]

They don't have plenty of memory in comparison to a modern laptop or phone. Most do have plenty of memory in comparison to desktops from the 80s that were able to run BASIC interpreters at a reasonable speed. A lot of them have plenty of memory in comparison to a '70s Xerox Alto that could run an entire GUI written in a garbage-collected pure OO language.

Re: Surprise? Why?

[hackwrench]

I'm not talking about "after each use". At least, in any sense that you aren't resetting it after each use either way. Just that some calling methods "reset" the stack on return by the called procedure, or on architectures without a return instruction that has a parameter that specifies how much to adjust the stack by, immediately before, or immediately after by the calling procedure. Having the calling procedure free the stack means that there is an extra instruction each and every time a call is made. The called procedure has to modify the stack anyways when the space of the address to return to is adjusted on the stack.

Re: Surprise? Why?

[hackwrench]

I'm not sure what degree you are agreeing with me that it makes sense for the callee to do the stack reset as part of the return as opposed to the caller doing it. I don't understand the need of a frame pointer, though I am aware of the "enter" "leave" instructions on the Intel architecture. I'm sorry if you misunderstood me. Sometimes I have difficulty being clear.

Re: Surprise? Why?

[Bengie]

Leave the field. I have never met someone who "eventually learned". Programming seems to be bimodal. Either they can or they can't. There are those who can't and seem like they can, until you dig into their Rube Goldberg code only to realize it was working only by pure luck. These are the most dangerous "programmers".

One common characteristic that I've noticed with people who I would considered "programmers" is they can debug code without ever seeing the code or using a debugger. Computers are logical and you can reverse-engineer their high level designs based on their operational characteristics and there are only so many reasons why certain errors can occur. Using nothing but logic should be enough to debug most problems.

Re:Surprise? Why?

[K. S. Kyosuke]

You also don't need to know any assembly language if your computer doesn't have one. For example, the Oberon system is just Oberon.

Re:Surprise? Why?

[angel'o'sphere]

That is not the point.

And I'm pretty sure you can write Oberon modules in Assembler if you want.

Point is: being good or even knowledgeable in Assembky is completely irrelevant for the question if one is a good coder/programmer or not.

It gets more and more irrelevant when you consider massive parallel architecture etc.

The parent does not even know that old school programmers in the 1950 (General Data comes to mind or Honywell and Bull etc.) never really used Assembler. Basically all business applications where written in Ad Hoc invented 'business byte code'. A small virtual machine was implemented for every 'topic', and the problems and business cases of such topics where programed using that virtual machine byte code.

Of course you used a macro assembler for that.

Think about Sweet16 but on a much higher level.

Re:Surprise? Why?

[Megol]

80x86 was what was written. Also known as x86 (which just removes the first two chars from 80x86). In most cases x86 is used to refer to the 32 bit extension (i386) or, like here, the 64 bit extension. That is also known as AMD64 (as AMD introduced the extension), Intel64 etc. and also x86-64 - which is used in the project in question.

https://github.com/tthsqe12/as...

Observe: "Welcome to the project of converting stockfish into x86-64".

So what are you talking about exactly?

Re:Surprise? Why?

[angel'o'sphere]

Don't know.

What exactly are you talking about?

The original parent wrote 8086 ... at least I read it that way.

Regarding the project, it is unclear if he is converting the existing code routine by routine, or doing a complete rewrite.

Having a speed increase b 10 - 20 percent is impressive, but pretty meaningless for real life software projects. You basically pay 10 - 100 times the price verus C/C++ to write the same code in assembly.

Re:Surprise? Why?

[Megol]

Compiler writers aren't generally skilled in assembly language programming.

To be fair, neither are most people writing assembly language. Most people I've worked with in this area certainly didn't have an exhaustive knowledge of all the available opcodes and their detailed performance characteristics on every processor architecture we targeted. I'll be the first to admit that I didn't.

However, some of the best assembly programmers I've known have been working on compilers. It makes sense to hire those people to work on code generators used by millions rather than to hand craft assembly for individual projects.

Have you ever written any assembly code?

Yes, professionally, for some years, on several different architectures, and in performance-sensitive applications. These days I read assembly a lot more than I write it, for exactly the reasons we're discussing here.

Because writing code for an OoO processor without obvious weaknesses (like the Pentium 4 had) is trivial.

Perhaps, but Pentium 4 was hardly the same as today's major CPUs from the likes of Intel and ARM. It's not as if writing an XOR to zero a register is the most tricky thing to get right any more.

Caches have to be taken into account as much as in high-level languages, pipelines aren't a problem, I don't know what you mean by predictive execution - if it's speculative execution one can generally ignore it altogether, parallel operations is another mystery - if you are referring to SIMD it's actually simpler to code in assembly.

The thing is, though, that good compilers for high level languages can look at much larger areas of the code and systematically optimise them, thus making better use of finite resources like cache capacity.

Will your hypothetical assembly programmer consistently rewrite their functions to perform the appropriate level of inlining and fusion effects based on context? Modern compilers for some high-level languages already do.

So we are discussing scientific code? General purpose code will not get huge advantages from advanced inlining etc. I don't know what you mean by fusion - the only thing that comes to mind is loop fusion.

And the answer is of course yes.

Will your hypothetical assembly programmer rewrite their entire function a different way with more efficient register allocation if the underlying algorithm changes? (Granted this one is less relevant these days if we really are talking about a relatively high-end CPU with plenty of registers available anyway, but not all CPUs have that luxury.)

I'd hope so given the fact the code have to be rewritten. Register allocation is one area where a good compiler often is better than a skilled assembly programmer as generating the perfect schedule is very work intensive. In practice a skilled assembly programmer will not be far from optimal by simply using heuristics. Even a good compiler today (GCC, LLVM) can have problems with placing spill-fill of registers and that interacts with the register allocator and a lot more.

Will your hypothetical assembly programmer rewrite an entire hierarchy of functions a different way to avoid both blowing the FPU register stack and spilling unnecessarily?

I don't think there would be an hierarchy in the optimized case. IME compilers are very bad in handling the register-stack hybrid while assembly programmers are capable to handle them after a learning period. Intel even made the FXCHG instruction faster so that compilers could treat the FPU stack as a kind of register file.

Or was as nobody not requiring extended precision floats use the x87 instruction set any more.

Will your hypothetical assembly programmer detect implicit parallelism in their algorithms and restructure them to use parallel low-level operations (as in SIMD) and/or m

Re:Surprise? Why?

[UnknownSoldier]

>> If you do not know assembly, you cannot be a really good coder
> That is bollocks.

Only shitty programmers are clueless about assembly, which in turn implies they lack an understanding of memory access patterns.

Hint, try *reading*: Pitfalls of Object Oriented Programming

Even Bjarne Stroustrup, the designer of C++, until 2012 was completely cluess _why_ doubly Linked Lists were so slow compared to Arrays

HINT: Managing the L1 Cache usage is critical for performance sensitive code.

Programmers concerned about speed use Data-Orientated Design. For details see CppCon 2014: Mike Acton "Data-Oriented Design and C++"

Knowing when to use, and NOT to use OOP, makes a programmer better. Using design patterns without *thinking* shows others you don't understand programming.

--
Wanted: An Apple 2 Thunderclock Plus peripheral card.

Re:Surprise? Why?

[Anonymous Coward]

> It's also worth remembering that C++ is still quite low level on the programming language spectrum

No, it really isn't. It has a lot of high-level features cribbed from other languages.

It's probably fair to say that C++ is a very broad language.

Re:Surprise? Why?

[Anonymous Brave Guy]

So we are discussing scientific code? General purpose code will not get huge advantages from advanced inlining etc.

I'm assuming we're talking about something where performance actually matters, for sure. If the problem doesn't require particularly efficient code given the speed of the system it's going to run on, it's probably not very useful to drop down to assembly anyway, nor to consider how well the code generator for a high level language optimises its output.

I don't know what you mean by fusion - the only thing that comes to mind is loop fusion.

It's a general category of optimisations used when you're composing multiple operations over the same stream, data structure, etc. A typical example might involve a programmer writing some list processing code as filtering with one function, composed with mapping with another function, composed with reducing using a third function to get the final answer. An optimising compiler might merge those operations into one space-efficient loop that calculates the final answer without ever generating the intermediate lists.

Put another way, fusion is similar in effect to applying some combination of inlining and loop-based optimisations in situation where you're composing multiple operations over data sets, with the goal of eliminating the storage of unnecessary intermediate values and the overheads of passing them around. It's particularly relevant with higher-level languages that describe their data crunching in functional terms, where a naive implementation is much slower than the fused version.

If you know assembly programmers who would routinely apply that degree of tight cross-function optimisation (and maintain the code well as the underlying functions evolved later) then I'll be both genuinely impressed at their diligence and somewhat disturbed at how much redundancy they must have in their code base.

I don't think there would be an hierarchy in the optimized case. IME compilers are very bad in handling the register-stack hybrid while assembly programmers are capable to handle them after a learning period.

I'm not sure that's entirely correct. Even when I did more work on these things a few years ago, compilers were already doing cross-function optimisation right down a call stack to optimise the use of the floating point register stack.

I brought this one up as another example where if you were writing the functions manually in assembly, you'd have to either devise your own custom calling conventions for every case (and so potentially reimplement the same functions multiple times) or accept less than optimal performance. As you point out, it's probably not the best example in the context of current CPUs, though.

Most code isn't compiled with whole-program optimization. In fact a huge amount of software are compiled with little optimization done.

Maybe, but then most code isn't developed with hand-tuned assembly for its hot spots either. I'm assuming that we're talking about performance-sensitive cases where that kind of effort would be justified, and that we're interested in which strategy is likely to give the best results in practice. My contention is that, in 2016 and on most modern CPUs, it is likely that using a high level language and a good optimising compiler will give better results than most people would achieve by dropping to assembly.

Re:Surprise? Why?

[Anonymous Coward]

> The original parent wrote 8086 ... at least I read it that way.

Read it again, please.

Re:Surprise? Why?

[Anonymous Brave Guy]

It really is, in the sense that it allows all kinds of fine low-level control over the data you're working with. Pointers and aliasing, mutability by default, imperative programming style often with manually constructed control flows, global state and often shared state if concurrency is in use... These things all introduce ambiguity into the programmer's intent and so make unsafe the assumptions that would support lots of different optimisations.

In short, optimisation is usually not about the upper bound of where a language lives on the abstraction spectrum, but the lower bound.

Re:Surprise? Why?

[angel'o'sphere]

Sorry,
No idea why you are ranting like that.
In Java you have no influence in caches etc.
In C already it is limited.
And frankly: I don't need to read your links for education. Only perhaps for amusement and for correcting the errors in them ;)
Your "lack of understanding of memory access patterns" has nothing to do with assembly or C++.
I guess I was the first one writing simple template based data structures + custom operator new - libraries that tried to exploit caching behaviour (1993 or so?). However that has nothing to do with assembly ;)

Re:Surprise? Why?

[Opportunist]

I think I wrote somewhere else that the compiler in the Atmel Studio is one of the worst when it comes to optimization. You might want to do the final compile using gcc, that actually does some pretty good optimization.

Gonna call bullshit on that too?

Re:Surprise? Why?

[Pseudonym]

ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.

Incidentally, the C standard contains a lot of undefined behaviour which isn't there to ease porting to obscure platforms, but to enable optimisations that only seem to give a measurable performance improvement in highly artificial benchmarks.

Re:Surprise? Why?

[UnknownSoldier]

Only shitty programmers continue to make excuses why they are shitty.
Arrogance is assuming you THINK you already know.

> In Java you have no influence in caches etc.

FALSE.

Do you actually understand _anything_ about cache lines???

HOW you access memory determines your maximum throughput.

Proof: Here are two different ways to sum up an array:

1. In the first example we access every 0th, 16th, 32nd, 64th element. Then 1st, 17th, 33rd, etc. Then the 2nd, 18th, 34th, etc. Our stride is 16 elements.
2. In the second example we access every element in a contiguous fashion. Our stride is 1 element.

If one "had no influence in caches" like you ignorantly assume the timing would be identical. However one is SLOWER then the other.

Copy and paste into an online Java compiler

public class HelloWorld{
 
    public static void main(String []args){
        final int _K = 1024;
        final int N = 2048 * _K;
 
        int[] a = new int[N];
        int sum;
 
        long start, end, dur;
 
        for( int i = 0; i < N; i++ )
            a[i] = i & 0xFF;
 
        start = System.nanoTime();
        sum = 0;
        for( int j = 0; j < 16; j++ )
            for( int i = j; i < N; i += 16 )
            {
                sum += a[ i ];
            }
        end = System.nanoTime();
        dur = (end - start) / 1000000; // milliseconds.
        System.out.format( "Sum: %d, Time: %d\n", sum, dur );
 
        start = System.nanoTime();
        sum = 0;
            for( int i = 0; i < N; i++ )
                sum += a[ i ];
        end = System.nanoTime();
        dur = (end - start) / 1000000; // milliseconds.
        System.out.format( "Sum: %d, Time: %d\n", sum, dur );
    }
}

> Your "lack of understanding of memory access patterns" has nothing to do with assembly or C++.

If you would actually _watch_ and _learn_ you would recognize this is false.
https://youtu.be/rX0ItVEVjHc?t...

> libraries that tried to exploit caching behaviour (1993 or so?). However that has nothing to do with assembly ;)

Here's your cookie for missing the point"

Assembly language programmers tend to be more knowledgeable of when and where their code is slow. C++ and Java programmers tend to be more ignorant of high performance because they generally don't have a clue _how_ the compiler is generating the corresponding asm for their code -- and then they wonder why it is slow.

A good programmer learns assembly to better understand how to write simpler, smaller, and faster code.
A shitty programmer makes excuses for why they don't understand assembly.

Re: Surprise? Why?

[asm.supermaster]

People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.

Maybe, but not optimized programs in assembly language are much faster than not optimized programs in high level languages. And as long as 99% of the code is not optimized, the result is predictable - the assembly language programs are faster almost always.

Re:Surprise? Why?

[UnknownSoldier]

TL:DR; You need to learn HOW to optimize:

@37:30 -- Mike Acton: Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize

- - -

> If you want speed, assembly is the ONLY option.

Total NONSENSE.

A. You keep implying this word optimization -- it doesn't mean what you think it means!

B. There are four lights, er, types of optimizations:

1. Use a lower level language
2. Micro-optimization or Bit-twidling
3. Algorithm
4. Macro or cache-orientated, aka (Data-Orientated Design)

What do these mean?

1. Use a lower level language

With bloated languages and incorrect use of C++, Java, etc., inexperienced programmers naively thing changing to a "lower level" language -- such as C or Assembly -- will help speed up their code. While it is true one has access to more programming paradigms in a low level language, i.e. you can use the carry flag as a return value instead of wasting an entire byte with assembly, this type of optimization only takes you so far before you need to look at alternatives.

2. Micro-optimizations

All good programmers should read (and understand!) these bit twiddling optimizations:

* bit-twiddling hacks
* Hackers Delight

While compilers can generate "good enough code", sometimes hand-optimized instructions can beat the compiler. e.g. Before compilers optimized division with reciprocal multiplication, a common technique for division was to manually change division into reciprocal multiplication. i.e. `/ 3` -> `* 1/3` which means you would see something like this:

int a = 123 / 3;

would be replaced with:

int b = (123 * 65536 / 3) >> 16;

Thankfully most compilers will perform these integer divisions but you can try this out with an online C compiler:

#include <stdio.h>

int main()
{
int a = 123 / 3;
int b = (123 * 65536 / 3) >> 16;
int c = a == b;
printf( "a: %d =%d= b: %d\n", a, c, b );

return 0;
}

These types of micro-optimizations are becoming rarer and rarer as compilers (slowly) get better. However Don't assume. VERIFY your assembly output of the compiler.

Floating-point optimizations still show up. The most famous is probably John Carmack's Quake 3 Inverse Square Root

This PDF provides a very good explanation:

* http://www.lomont.org/Math/Pap...

3. Algorithm

The fastest way to optimize (from the programmer's run-time) is to replace a slower algorithm with a faster one.

i.e.

* If the common case for your data is unsorted, then replacing a dog-slow bubble sort with quick-sort will show gains.
* However, if the common caseis that the is 99% mostly sorted, then changing algorithms may not always help.

This is where most people start to optimize. BUT, notice how I said "Common Case". There is a _higher level_ of optimization we can do:

4. Macro or Cache-orientated.

The 0th rule in optimization is:

Know Thy Data

When you optimize you need to optimize for the common case. This means understanding data flow, Memoization, and transforms. You _must_ question ALL assumptions, knowns, and unknowns. What, exactly, are you trying to do? i.e. Printing Primes and Printing

Re:Surprise? Why?

[gweihir]

A good programmer learns assembly to better understand how to write simpler, smaller, and faster code.
A shitty programmer makes excuses for why they don't understand assembly.

And that is just the point. Most of the excuses here have stayed the same for the last few decades and are just as invalid today as they where back then.

Re: Surprise? Why?

[gweihir]

These are decidedly special cases and you get no argument from me.

Re:Surprise? Why?

[UnknownSoldier]

Whoops, forgot the link to Mike Acton's talk:

Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize
* https://youtu.be/GPpD4BBtA1Y?t...

Re:Surprise? Why?

[UnknownSoldier]

I too have worked on a C++ compiler (PS3).

While it sounds like you are very knowledgeable in the first 3, sadly, it sounds like you don't understand the 4th level of optimization aka Data-Oriented-Design. :-/ The levels of optimization are:

1. Use a lower level language
2. Micro-optimization or bit-twiddling
3. Algorithm
4. Macro-optimization or cache-orientated aka Data-Orientated Design

I think you'll enjoy these links:

* Pitfalls of Object Oriented Programming

and

Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize

> or perhaps recoding Java into C++.

Unfortunately, this is the 1st level of optimization by the inexperienced and is the *wrong* place to start.
You need to look at the *data first*, NOT the code before you start optimizing.

Switching implementation languages is (usually) a symptom of NOT understanding the problem.

"Show me your flowchart and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won't usually need your flowchart; it'll be obvious."
-- Fred Brooks, The Mythical Man-Month.

The modern vernacular paraphrase is:

"Show me your code which obfuscates the data (structures) and it will take a while before I can understand / optimize it.
Show me your data and I won't need to see your code."

Here is my post where I explain the 4 levels of optimizations in greater detail.

Re:Surprise? Why?

[UnknownSoldier]

Yup, I use ca65 directly since c65's code generate is so horrible.

Re: Surprise? Why?

[Bengie]

There was a paper at ASPLOS two years ago that showed that you get a 30% delta on most programs from randomised code layouts just from different cache interaction

What's funny is when someone micro-benchmarks the heck out of something and shows me empirical "evidence" that their code is faster than mine. Then they put the code into production and their code is suddenly running really slow under heavy load. Throw in my code for S&Gs and suddenly the service is running much faster, and I don't even put much effort into the design like they do. Many people fail to understand how processes within the system interact with each other when it comes to cache and memory bandwidth. Even when I try to explain my theory as to why my code runs faster, their eyes glaze over. And that's why many of our services run like crap.

Re:Surprise? Why?

[Bengie]

In other words, a 100% increase in performance of a micro-benchmark can result in a 10% reduction in the macro-benchmark.

Re:Surprise? Why?

[Anonymous Coward]

My first reaction was, machines have languages - languages don't have machines.

But your mention of Oberon (the OS based on the language) intrigued me, so I looked it up. It appears to have been developed on NS32000 series chips, which did have an assembly language for their ISA, but evidently no native assembler. You had to use a cross-assembler on another machine to write code for it. Mind blown.

Re:Surprise? Why?

[jeremyp]

If you are on an 8 bit MCU, speed is critical because you wouldn't be on an 8 bit MCU if you had a choice to use larger faster hardware.

Frequently the programmer has no choice about the hardware but is still required to make the code as fast as possible.

Re:Surprise? Why?

[angel'o'sphere]

How dumb are you?

You are mixing up memory access patterns with data structures.

class Part {
int data;
}

class Composite {
Part (*)somePart;
}

In C++ I can over load operator new() so that all Parts are 'close' their Composite.
In Java I can't.

But thanks for your idiotic post ablout my ignorance. Idiot

And all your idiotic ranting has nothing to do with assembly anyway. A processor cache works more or less the same regardless what language you use or what processor architectue... Idiot, as you just have shown yourself. Idiot

Chance is that I speak more assembly languages than you idiot anyway, and no: it does not help me write better C/C ++ or Java. It is completely irrelevant

Re:Surprise? Why?

[Boronx]

Little $2 8-bit microcontrollers are all over the place. They are cheap, low power, small. They are also slow. (20 MHz or less).

As it should be

[Anonymous Coward]

Finally

wat

[drinkypoo]

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.

Wait, my toothbrush or coffee machine is capable of running assembly code? Normally, they only run bytecode that's been compiled from assembly code. I got my toothbrush for ten bucks with a charger, that's awesome! What's in there, an assembler or an interpreter? Either way, it must have a seriously overkill microcontroller.

These ratings are based on search results. Pardon my skepticism. From what I can tell, more and more microcontrollers are being programmed in C these days.

Re:wat

[Anonymous Coward]

My coffee machine runs on Java direct - none of this assembly or bytecode nonsense!

Re:wat

[slowdeath]

Do you understand what 'programmed' in assembly means? Does not mean there is an assembler or interpreter on the device, only that the source code was written in assembler for some processor architecture, assembled to a binary image, and then programmed into ROM/FLASH/etc on the target device.

'Programmed in C' does not mean your fancy toothbrush has to have GCC running on it to be able to do its thing any more than 'programmed in assembler' does.

Re:wat

[BarbaraHudson]

Programs written in assembler do not need to be installed into rom or flash to run. Welcome to the 80s.

Re:wat

[EmeraldBot]

My coffee machine runs on Java direct - none of this assembly or bytecode nonsense!

This is hilarious not only for the pun on coffee, but also because some coffee machines actually do run on Java. I am actually quite interested how that would work - I believe you can compile Java to regular assembly, as I believe Android 5+ does, but I'd imagine it wouldn't be worth it for that case since C would do the job too. So if you use a regular JVM, or even a customized version, I'd imagine you'd need some sort of proper OS too.

Re:wat

[drinkypoo]

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.

Wait, my toothbrush or coffee machine is capable of running assembly code?

Do you understand what 'programmed' in assembly means?

Do you understand what single quotes are for? Are you new?

Re:wat

[Anonymous Coward]

My coffee machine runs machine language on a 1-bit CPU: a bimetallic spring. When the water is cold, it makes contact allowing current to flow through a heating coil. When the water's boiling it clicks off. I pour the hot water over the grounds. Works well, and reasonably quick, and the only "cloud" involved is the steam from the hot water.

Re:wat

[Opportunist]

I prefer to do smaller Cs in Assembler. In real time systems it can be important to know EXACTLY how many cycles an set of instructions will take. You can also carefully craft a routine to have exactly the same run times no matter the branch it takes, which can be very important in areas where reliable timing is key (e.g. if you want to avoid that your encryption get broken by a timing attack, or when you're dealing with crap like the USB protocol which barfs the moment you're just a liiiiittle bit off).

Re:wat

[Opportunist]

That C was supposed to be mC.

Say, when were we supposed to get unicode support?

Re:wat

[geezer nerd]

Thank you for shedding some useful light on this discussion. It is in danger of sliding off the rails. Education of "modern" coders seems to have omitted teaching programming history and the evolution of programming technology.

Re:wat

[thinkwaitfast]

If you want to know what this is all about read EEVblog #284 – Braun Toothbrush Teardown There is also a youtube video worth watching. It talks about the microprocessor inside a toothbrush.

And you thought you were joking.

Re:wat

[Anonymous Coward]

Don't be an ass. You intentional missunderstanding and ranting about it is not funny.

Re:wat

[Anonymous Coward]

If you intend to run Java on a microcontroller you should pick an ARM with Jazelle support or an AVR32.
That way the controller will do the translation from Java bytecode into microcode directly and you can ditch the conversion phase.

Re:wat

[Lisandro]

I tend to think of C as portable assembler. It is not hard to get an idea of the compiled result of a program just by looking at its source code.

Re:wat

[Anonymous Coward]

That's a horrible idea, among several other reasons because there are no optimizing Java bytecode compilers at all!
To get usable performance out of Java you absolutely MUST run a JIT.
Unless you plan on writing Java bytecode directly...

Re:wat

[Megane]

That sounds great until you have to take that six-year old product that was done in PIC assembly (Which PIC? You mean there's more than one?) and make a new product based on what it did. Now you have to decode the algorithm out of the assembler code. (Sorry, you can't ask the old guy, he left three years ago. He wouldn't understand his old code anyhow.)

Not that C would have been much better on PIC, which is a horrible architecture for it, but at least you could have a chance to see the algorithm, not a hundred assorted register moves and branches with little indication of program flow structure. Fortunately, microcontrollers have been moving toward architectures designed for high-level languages. PIC and 8051 are basically the only old-school 8-bit assembly still being used, and 8051 isn't compiler-hostile like PIC. (code bank switching is bad, mmmkay?)

There are very few cases where you really need to care how many cycles an instruction takes (and now you can't even be sure anymore!), and very few cases where a modern one-dollar CPU isn't already a hundred times faster than you need. There is no need to optimize code for speed when it is executed once per second, or to optimize for space when you can usually double your flash size for a few pennies more. Hand-optimization effort is wasted on anything less than tight inner loops for time-critical stuff.

Re:wat

[drinkypoo]

Don't be an ass. You intentional missunderstanding and ranting about it is not funny.

You think your response was? Thanks for opening your mouth and removing all doubt.

Re:wat

[fnj]

GP was quoting the summary, which said "Even your toothbrush or coffee machine are running assembly code nowadays." "Running", NOT "programmed in". Your attempt to upbraid drinkypoo has FAILED.

So who is the idiot who doesn't understand?

Re:wat

[fnj]

What the fuck? Are you not fluent in english? Do you not comprehend the difference between "running" and "programmed in"? Re-read drinkypoo. He's on the money.

Re:wat

[Giant Electronic Bra]

There have been Java to GCC intermediate representation translators forever, basically since like 1998. The issue there is simply that many dynamic features of Java effectively can't be translated to machine code, so only a subset of Java is translatable. The other issue is that JITs are EXTREMELY sophisticated optimizers, much more so even than C compilers (because they can analyze the run-time behavior of the code and do on-the-fly optimizations AS WELL AS anything a C/C++/Whatever compiler could do statically). There are tools to dynamically optimize or simulate ASM/HLL code to achieve similar results, but they require a lot of expertise to use and cost developer time, and therefor money, to run. Java OTOH just does it.

In fact, in MANY cases, Java programs are faster than C/C++ equivalents. This is especially true for large, long-running, applications like servers and whatnot.

Beyond that, Sun produced a whole line of chips in the 90's that run Java byte code directly, so your JVM simply ran application code on bare metal and provided OS type services via in-VM implementations. I don't know if embedded Java stuff uses that sort of approach or exactly how they do it, but my guess is they have very lightweight runtimes that are simply compiled into a JVM. Its not as if JavaME requires some huge amount of OS functionality. It has to have some degree of 'file system' perhaps, but that can be a quite primitive affair that simply associates an InputStream with a name. Likewise they don't need to worry about many of the APIs at all, so the whole thing can be quite small, many functions like security managers and classloaders and such are just stubs, etc. I'm guessing you practically speaking need some sort of 32 bit processor, but things like FreeScale ColdFire+ and low power ARM based designs are now EXTREMELY low-end. There's still some stuff running old 8-bit and 16-bit 80's processors but those are getting fewer and further between. The only real exceptions are the ultra-low energy IoT stuff, remote unpowered sensors running on ambient power and such. Most of those are probably programmed in FORTH anyway.

Re:wat

[Bing Tsher E]

The only reason I use high level compilers for PIC and AVR parts is the library support. It's nice to just bolt on I/O components. Other than that, the abstraction of a high level language just gets in the way.

Modern low-cost CPUs aren't 'One Dollar CPU's incidentally. They're 6-20 cent CPUs. "A few pennies more" is a big deal and management won't approve of it.

Re:wat

[geezer nerd]

I have understood that difference likely since before you were born. I spent a good piece of my career creating code to run embedded on small devices (and some not so small). No, I don't think "dinkypoo" is on the money. I was trying to compliment/encourage "slowdeath", who I think has a really good understanding of the issue. I find your rudeness to be really quite intolerable.

Re:wat

[TheRaven64]

If you really think that, then I'd suggest that you read our recent PLDI paper: Into the depths of C: elaborating the de facto standards. We asked a load of people on the C standards committee, C developers, and C compiler writers about the semantics of various C programs and got very different responses.

Re:wat

[TheRaven64]

There have been Java to GCC intermediate representation translators forever, basically since like 1998. The issue there is simply that many dynamic features of Java effectively can't be translated to machine code, so only a subset of Java is translatable

That's not really true. There's nothing in Java that you can't statically compile (look at Android, for example, which now does AoT compilation for all of the Java code). The problem is that a lot of things in Java are a lot more efficient if you have realistic run-time profiling information and even more efficient if you can do some optimisations speculatively and then undo them if they were wrong. For example, Java programs typically call a lot of small methods. If you have a class that's marked final, then you can inline them in an AoT compiler, because they can never be replaced by a subclass implementation (possibly unless you use reflection? I've not looked at recent Java reflection support much), but if the class is not final then you can't. If you run the caller 1,000 times and every single time it happens to be called with an object of the same type, then you can inline that version with a very cheap check. If there's then a phase change in the program and it starts being called with a different class, then you can regenerate the code in a JIT and replace it with something more generic, or specialised for the other case.

In fact, in MANY cases, Java programs are faster than C/C++ equivalents. This is especially true for large, long-running, applications like servers and whatnot.

That's almost always due to the GC, which scales a lot better to lots of concurrent communicating threads than most malloc/free implementations combined with either shared pointers or trying to keep track of ownership.

Re:wat

[Lisandro]

Interesting read, i'll give it a look. Thank you.

Re:wat

[Giant Electronic Bra]

Well, yes, trivially JVMs are C/C++ programs and thus anything you can do in Java you can compile down to machine language, just like you can a C program. Truthfully though in many cases its not practical to do so because functionality depends on being able to reference the Java bytecode representation of the class for various purposes (as an example). Now, you could, TECHNICALLY, retain such a representation for each class within your code (assuming there's a bounded set of classes) and you could include an entire byte-code-to-machine-code translator to translate classes that are dynamically loaded, and on and on and on, but its obviously just ridiculous at that point. Thus MOST modern Java applications are simply not candidates for conversion not because the technology can't exist or doesn't (for the most part) exist, but because its simply not a good idea.

GC is only part of the whole equation with Java efficiency. A LOT of it also has to do with runtime optimization of code. Over time a JVM can make a lot of inferences and learn a LOT about code and make many tweaks that are forever beyond a static compiler. The JVM also has a perfect understanding of what parts of the code NEED to be optimized, something developers rarely experience in practice. There are still vast areas where much greater improvements can be achieved as well, such as locality awareness, which isn't currently a real strong point of JVMs. As the world shifts more and more back to a dumb client/smart server kind of processing model Java's efficiency characteristics keep serving it better and better (not to say there aren't even more advanced ways to get there, but Java is a very practical alternative).

Re:wat

[TheRaven64]

Java doesn't have sub-method reflection. The object model is very similar to (actually, slightly simpler than) Objective-C, which is AoT compiled. The only time you every look into the bytecode is during code generation. For everything else at run time, you just need class structures in your object code, something that Objective-C has happily done since the '80s. Given the number of Android devices that use AoT compilation for Java (i.e. all of them that run a vaguely recent version of Android), it's pretty hard to claim that AoT compilation for Java is not practical.

Re:wat

[Giant Electronic Bra]

Well, Objective-C is irrelevant, its a language that was designed from day one to be compiled to machine language. Dalvik is also QUITE DIFFERENT from actual Java. While a LOT of Java source, particularly for straightforward and relatively static user-facing applications, will compile and work on Android, the vast majority of actual Java application code, backend server stuff running in JavaEE environments for example, that requires dynamic class loading, including security management etc, is not suitable for this kind of treatment. If you, as an Android developer, have gotten the impression that "any Java can be run on Android, its just a matter of APIs" this is a false impression. Likewise with other products like RoboVM. Its not that it cannot be done of course, as I said before anything is possible, but once you get to the point of basically reproducing ALL of the functionality of the JVM, dealing with validating bytecode, supporting code injection (necessary for any IOC container), etc then you've probably evaporated most or all of the benefit, since Java isn't exactly that far behind native code to start with. This is why AoT has essentially gotten little or no traction in the enterprise world. There are allowances in some JVM's to maintain JIT state between runs of JVM, which can deal with some issues of performance at startup, etc, but nobody is compiling these server-side apps down to machine code. Certainly not in any market segment I've been exposed to so far.

Re:wat

[Anonymous Coward]

To be fair that has never been contemporarily public information, and likely won't be for quite some time.

Re:wat

[Anonymous Coward]

In real time systems it can be important to know EXACTLY how many cycles an set of instructions will take.

What?? By the time I stopped writing things in assembler (specifically 16-bit 8086/80186/80286 code), it was no longer possible to know how many cycles a given instruction would take. Timings varied according to instruction prefetching by the time of the '286. Way before that, in Z-80 code, I could add up cycle times and be sure of the timings. By the time processors starting supported things like multiple pipelines, figuring instruction timings by hand got to be pretty well hopeless. I decided then I needed to start trusting the code generators in the compilers.

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.

Re:Not convinced

[Anonymous Coward]

Same. I do embedded for a living. We program for many different lines of CPUs and MCUs from different manufacturers and with different architectures. I can only think of one specific function we've done in assembly for one project in the last decade. Our last "all assembly" projects are dating from the mid 90's.

Re:Not convinced

[Darinbob]

Nut even on those devices you need assembler to do some basic stuff. Writing the C library, writing the OS, writing interrupt handlers, making use of system level machine options (there's no "C" operation to control caching for instance).

Re:Not convinced

[Darinbob]

Then I assume you're paying a third party to supply libraries for you, operating systems, startup code, BSPs, etc. Which means those third parties are using the assembler even if you aren't. I do embedded for a living, and I have to do assembler - not everyone working on the software does but some people do.

Re:Not convinced

[Austerity Empowers]

There are good reasons to work in assembly, particularly in systems programming. Or if you don't want to pay licensing fees for an OS, you may need to implement functions in assembly that are not possible in a high level language like C (manipulating machine state registers, implementing barriers, etc.).

I have been using assembly for various architectures for my entire career and most of my teenage life, I don't see any reason why it would ever go away. Mostly the number of people doing high level development has increased so radically that it honestly surprises me that it makes #10. Optimization for performance is definitely not a reason I'd expect to see asm hit #10 - most companies don't spend enough time on their applications to get to the point where they can optimize intelligently, and writing something in assembly is not always or a performance enhancer.

Re:Not convinced

[Anonymous Coward]

Automotive checking in. Same here. Sure operating systems and boot code has some assembly, but we all try to minimize the amount of assembly.

Re:Not convinced

[geoskd]

Then I assume you're paying a third party to supply libraries for you, operating systems, startup code, BSPs, etc. Which means those third parties are using the assembler even if you aren't. I do embedded for a living, and I have to do assembler - not everyone working on the software does but some people do.

As a contractor, I have seen a large number of projects where the client wanted optimizations done for both space and performance so they could try to squeeze one more feature into an already barely capable processor. In all but one of those cases, it turned out to be more cost efficient to replace the microcontroller with a more modern one. In about a third of the cases, my solutions actually *reduced* unit cost because the client had been paying a higher per unit price for their uCs than what is currently available for much more powerful options. The most extreme example was stripping an old Freescale processor out of a product and replacing it with a modern cypress PSOC. The old processor cost $11.03 per unit, and the PSOC cost $1.57. The per unit savings paid for my contract cost in less that 2 years (including the new features they wanted). It almost never makes sense to resort to assembly unless there is a reasonable expectation of selling millions of units per year, and even then, it'll be close because powerful uCs have become so damn cheap lately. I can do it if thats what the customer really wants, but my job is to maximize the customers return on their investment in my time. I do very well because my customers get what they really want, not necessarily what they initially come to me asking for.

If you're out of compute power, your best bet is to look into getting a faster uC, or getting a PSOC, where you can offload a significant portion of your compute expense into programmable hardware.

Re:Not convinced

[geoskd]

(manipulating machine state registers, implementing barriers, etc.).

Funny, I never had trouble accessing registers using C. And if you're dealing with a processor that is powerul enough to be doing instruction re-ordering, you're probably not working in the embedded space anymore, and will almost definitely have an actual OS on your device which can and will handle those details for you.

Re:Not convinced

[gweihir]

There are also some pretty stupid limitations in C, for example, no access to the "carry" bit. Usually it does not matter, but if it does, embedding assembler is the way to deal with that.

Re:Not convinced

[Pseudonym]

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.

I've been involved in firmware development for small devices. In my (probably limited compared to you) experience, the ability to read and understand assembly is just as important as it's always been in that space, even if not a single line of deployed code is written in assembly. If I was hiring someone, I would put that in the job requirements. For TIOBE's statistics-gathering purposes, that may well translate to "assembly programmer wanted".

Re:Not convinced

[Darinbob]

And optimizers are sometimes stupid. Ie, you do the equivalent of rotate and such and it doesn't figure out to replace with a single instruction. Don't always need it, but is handy for optimizing crypto type stuff.

Re:Not convinced

[Rockoon]

There are also some pretty stupid limitations in C, for example, no access to the "carry" bit.

This isnt a "stupid" limitation of C. Its just that the C abstract machine isnt low level in spite of the claims of modern C programmers.

In 1980 if you said that C was a low level language you would have been laughed at. By 1990 C had become so popular that the collective wishful thinking of C programmers erroneously adopted the notion that C was low level.

Now here we are today. C programmers are convinced that C is low level and cant imagine how anyone could have the knowledge to beat the compiler, because after all if they are low level programmers and dont know how, then how could anyone?

The farce is this large group of completely wrong people wishfully thinking that they are low level programmers. They dont know what the carry bit is that you mentioned. In their view, only a "master assembly language programmer" would know that stuff, because that certainly cant just be ordinary "low level."

Re:Not convinced

[Darinbob]

We're selling millions each year, and it's amazing the sort of silly things they do to save 2 cents, like having a processor that's just a bit too small. Though for what we have and the price customers want, we almost never have enough memory to be able to compile w/o optimization while debugging.

Re:Not convinced

[Anonymous Coward]

> Funny, I never had trouble accessing registers using C.

Hmmm. How exactly do you do that?

And by "that" I mean something like copying AX to BX.

Re:Not convinced

[Austerity Empowers]

Funny, I never had trouble accessing registers using C

Memory mapped registers? Sure, no problem. But you also have I/O mapped registers which require special instructions, as well as things like the arm machine state registers which have a family of instructions you need to use. Then there are things like memory and instruction barriers, they also require specific instructions that you cannot make C emit without a library call to an asm function. You have cache invalidates, semaphore mechanisms etc. All of this requires an assembly library at least.

you're probably not working in the embedded space anymore, , and will almost definitely have an actual OS on your device which can and will handle those details for you.

That depends very heavily on how you define embedded, what you do and who your employer is. I've done a lot of embedded work, I make no assumptions. Cell phones have very advanced processors and quite capable OSes. BMCs in x86 servers? Some do, some don't. Robotics controllers almost never have an OS, and some controller vendors make using C very difficult (I won't name names). At least as of 5 years ago my friend who does a lot of flight controls works very heavily with assembly, and there's a very rigorous process for how code is written and reviewed, some of those guys are positively allergic to operating systems - everything is a state machine with definite and well defined entry/exit criteria.

I don't think anything can be said about this field that can hold up in a general sense. Saying embedded is like saying "anything smaller than a PC", which includes a phone that is many times more powerful and complicated than any PC I had in the 90s (with an OS to match), all the way down to the AFCI fuses whose sole job is to detect electrical arcs and trip the breaker.

Re:Not convinced

[thinkwaitfast]

I never had trouble accessing registers using C

Odds are you do not know all of the registers on your chip.

Re: Not convinced

[jrumney]

Usually #include <vendor.h> ... BX = AX; or maybe _BX = _AX; will do it in most embedded C compilers.

Re:Not convinced

[Xenna]

You always get better results in assembly, but the cost is usually prohibitive. I think THOBE is just wrong here, look at my other post for an explanation.

Re:Not convinced

[Anonymous Coward]

It's quite possibly related to the rise of AVR and PIC micros. They're used in a lot of cheap products these days, and as you say, with very limited memory, assembly is frequently the best option.

Having played with ATtiny's quite a bit, I know from experience that high level coding uses a lot more memory. Even simple stuff like turning pins on and off is much leaner with direct port calls. And anything involving accurate timing is almost impossible without going low-level due to clock cycle overheads.

From a product perspective, increasing cost is a big no-no, so you go for the cheapest microcontroller you can. Knowing how to use assembly is therefore a big plus, even if you rarely resort to it. And of course, it's not all that difficult to learn since these are very basic chips. I'd expect many of the older coders here cut their teeth on 8-bits back in the 80s, and they (we!) were kids at the time.

Assembly on more powerful systems, yeah it's probably not needed. But at the low end it certainly has its place.

Re:Not convinced

[angel'o'sphere]

Funny, I never had trouble accessing registers using C.
Then tell us how you do it, so we learn something ;D

Re:Not convinced

[geoskd]

Then tell us how you do it, so we learn something ;D

For most chips, it is good enough to use the dev environment the manufacturer recommends. If you want to use your own dev env, the easiest way is to locate the hardware libraries from within the recommended dev env. Simply copy the libraries and headers. Most manufacturers will actually make this easier by providing those libraries and headers upon request. In the rarest of circumstances, the manufacturer will refuse or ignore the request. That is the time to re-evaluate the total cost of development with that chip, because they have just added a very large amount of work to your project, so the chip better provide some extraordinary value to offset this additional development cost.

For every "embedded" processor I have seen in the last 15 years, the manufacturer has a preferred dev toolchain. Don't fall into the trap of paying for it either. Almost all of the toolchains I use are free because the manufacturers understand that toolchains represent a limited form of lock in. The very idea that a vendor would charge you for the toolchain on top of the other benefits they get from you using it is insulting. To my knowledge the only major player left that does this is Freescale, and fortunately, there are other compelling reasons not to use their processors as well, so they never even make it into the later rounds of processor selection.

Re:Not convinced

[Megane]

You don't have dev units with the larger flash size variants of the CPU just so you can debug? It's one thing to care about millions of units, but when you're crippling your developers by forcing them to use a chip that the code barely fits in, that's just silly. (Yes, I know you want to be sure it works on the real product, that's why you still need to test on the real thing before release. That's no excuse for not having debug prototypes with more code space.)

Re:Not convinced

[Megane]

Having played with ATtiny's quite a bit, I know from experience that high level coding uses a lot more memory. Even simple stuff like turning pins on and off is much leaner with direct port calls. And anything involving accurate timing is almost impossible without going low-level due to clock cycle overheads.

You still don't necessarily need assembly language for that. While many platforms may helpfully give you some kind of GPIO library that won't let you toggle pins at more than 100KHz or so, just declaring the raw GPIO registers as volatile pointers is likely to get you the same kind of space and speed improvements as raw assembly, at the cost of your code being more closely tied to a limited number of SoC architectures.

Which you can deal with if you need to by abstracting for architecture at the next level up, writing an optimized version for each architecture you need to support, along with possibly a generic C version for reference. It's still going to be more portable for future architectures than straight assembly language, which will be important if you plan to sell your product for more than a few years. Old CPUs cost a lot more than newer ones, and give you a lot less. And that's even when you don't count the costs of old obsoleted chips going out of supply, or a change like 5 volt logic going away.

Re: Not convinced

[Anonymous Coward]

How many free compilers are there for stm8? Just sdcc :-( so we chose to pay $5000 for iar which im not happy about.

Re:Not convinced

[AmiMoJo]

Sometimes assembler is just easier. You can do something in C by carefully writing you code to ensure the compiler products the output you want, but it's simpler to just throw in some assembler.

The classic example is timing critical code. Many microcontrollers protect the registers controlling important functions like the watchdog or CPU clock by requiring a specific sequence of writes within a few cycles. You can do it in C, but most people just throw in a bit of assembler.

Re:Not convinced

[Anonymous Coward]

And for those purposes there's the ability to do asm routines in C. Having written plenty of asm in my day, you really don't want to do large projects in it. It's a right bloody nightmare.

Re: Not convinced

[Anonymous Coward]

So you're calling assembly routines from C?

Re: Not convinced

[jrumney]

You're not calling anything. It doesn't take a function call just to assign a register value to another register's value. Most embedded C compilers let you do that with C syntax, as if they are normal C variables.

Re:Not convinced

[slashdot_commentator]

Optimization for performance is definitely not a reason I'd expect to see asm hit #10 - most companies don't spend enough time on their applications to get to the point where they can optimize intelligently, and writing something in assembly is not always or a performance enhancer.

You're looking at it all wrong. Companies are not hiriing assembler programmers to optimize performance (code execution speed). They are hiring them to optimize profits. They maximize their profit by either using cheaper components, or add enhanced function on the same production component to avoid redesign costs. And on embedded products, that requires an assembler programmer; hence the "demand".

Re:Not convinced

[Bing Tsher E]

A low level programmer is one who remembers to initiate or at least mask off all the timers and interrupts. When there's NOTHING but bare iron beneath your code, which starts from the reset vector, that stuff becomes important.

Re:Not convinced

[angel'o'sphere]

Erm, what has the dev tool chain to do with accessing a processor register from C?
Point is: you cant't access registers of a processor with pure C.

So your awnser makes no sense at all.

Re:Not convinced

[Anonymous Coward]

It may work well if its a pin-compatible replacement. If not, you're basically back to square one - producing a new PCB, fix eventual crosstalk/interference issues (eg. higher clock may need to change stuff around), and, of course, new certifications for RF/CE compliance, that can be very, very expensive, depending on the item you're building.

Re:Not convinced

[geoskd]

Erm, what has the dev tool chain to do with accessing a processor register from C?

The "standard dev env" supported by the manufacturer will include libraries that provide all of the control access you need. These are typically provided as C libraries (written in assembly, but with a C interface).

To use these, just copy the libraries and .h files into your dev environment of choice, and done.

Re: Not convinced

[geoskd]

How many free compilers are there for stm8? Just sdcc :-( so we chose to pay $5000 for iar which im not happy about.

I would start here

Although to be fair, my first question is: why ST? I have looked at them before, and every time I look, I can get a 32 bit uC from Cypress with more IO, and pay less unit cost than the cost of the 8 bit ST chips.

Re: Not convinced

[Anonymous Coward]

Ah, okay. So the compilers take nonstandard C. I haven't done any embedded stuff, but thanks for the insight.

Re:Not convinced

[angel'o'sphere]

First of all: your assumption that every C compiler comes with a library that allows you to access registers, is wrong.
Secondly: if the library needs assembly, you are obviously not accessing the registers from C.
The whole thread you started with your bullshit claim 'I have no problem accessing registers from C' is simply bollocks.
Considering that most C compilers support an asm {} keyword and allow to embedd assembler into the C code, your claim makes even less sense :)

Re:Not convinced

[TheRaven64]

Note that, although there's no standard C way of doing this, most modern C compilers do provide builtins for accessing the carry bit. These look like functions that return the result via a pointer and the overflow bit as a boolean return value, but when you get out of code generation they'll typically become an add (or multiply) and branch on carry.

Re:Not convinced

[Anonymous Coward]

That's where a) optimizers and b) compiler builtins come into play. WOrst case there is inline asm.

Re:Not convinced

[Anonymous Coward]

Especially on x86 / x86_64 asm code is usually the worst at optimizing. You can take your big C code and pick out one or two functions and optimize only them in asm with very specific CPUs in mind. E.g. write an MMX and SSE2 optimized flavour of an important function. But hey, now we have SSE3 and that code is comparatively crap.

Any compiler can be much more flexible and optimize better to both a wide variety of and specific CPUs. It can consider the effect of cache lines, cache size, TLB size, available opcodes and registers while in asm you have to rewrite each time to the specific use case. 99% of the time people advocating asm as faster do so with the wrong believe that they know better than a compiler. It's usually more a case of not knowing the language they claim is slower.

Re:Not convinced

[gweihir]

Well, there is something to your stance, but I think a language that has bit-shift should also have carry-bit access. Of course, it should also have rotate with and without carry, and maybe the real issue here is that CPUs were not standardized enough in that area when C was defined. Although the carry-bit has been very standard for a long time. On the other hand, one primary design criteria for C was that writing a compiler should be very easy (and writing a non-optimizing C compiler is pretty easy), and things like carry, rotate, etc. may just have been cut to keep the language small.

I do fully agree that anybody that does not know what a carry-bit is is not a low-level coder at all and that many people that fancy themselves low-level coders do not qualify as such.

Re:Not convinced

[sjames]

Agreed. Simply knowing how to program in assembly changes the perspective of a C programmer. It's fine to do embedded programming in a mid level language as long as you know more or less what that code will do at the machine level.

Re:Not convinced

[jeremyp]

Funny, I never had trouble accessing registers using C.

You weren't using C. There's nothing in C about accessing machine registers. Have a look at the C11 standard some time. It doesn't even mention the stack.

Assembly language for what machine?

[jfdavis668]

They are machine dependent.

Assembly for what processor architecture?

[slowdeath]

X86, ARM, AVR, IBM360, PDP8, or what? Just saying 'assembly' is not all that interesting. Processor architecture(s) would be interesting to know.

Re:Assembly for what processor architecture?

[Anonymous Coward]

Apollo Guidance Computer
http://www.ibiblio.org/apollo/index.html#Playing_with_AGC_assembly_language_

Re:Assembly for what processor architecture?

[Anonymous Coward]

Agreed. And here's also to hoping the 65xxx series makes a major comeback. What? Hey, don't give me that look, I'm serious.

Re:Assembly for what processor architecture?

[Anonymous Coward]

Hey, don't forget 6502 and 68000.

"Apple II forever!"
    -- Steve Jobs, shortly before killing off the Apple II line

Re:Assembly for what processor architecture?

[istartedi]

Just imagine how many virtual C64s you could host on a modern server. Augment the original instruction set with 32-bit and 64-bit modes, and you might really have something. I know it's not likely; but the thought of being able to run Jumpman in backwards compatability with a modern office suite kind of gives me the feel-goods. We'd probably have to use timers to event-trigger each instruction for games that ran flat out with delay loops!

Re:Assembly for what processor architecture?

[tepples]

For a 6502 renaissance, look no further than the dozens of new NES games released in the past few years.

Re:Assembly for what processor architecture?

[Anonymous Coward]

Clock cycle counter with regular timer interrupts to sync CPU cycle time and physical time was how I did it when I wrote my emulator. The hard bit was finding exact timing for everything (there was some guesswork involved for undocumented opcodes and a bit of creative interpretation for dram halts).

Mostly worked, but never did get it accurate enough for accurate sound reproduction.

Re:Assembly for what processor architecture?

[Anonymous Coward]

Maybe Steve meant "Apple II [will be remembered] forever!"

Re:Assembly for what processor architecture?

[thinkwaitfast]

em6882. Is there even a C compiler for that chip? There are many low cost chips like that in the world., Probably an order of magnitude more than x86 or arm combined.

Re:Assembly for what processor architecture?

[thinkwaitfast]

The 65xx chips are now implemented in FPGAs...and they still need programming. I'm serious too.

Re: Assembly for what processor architecture?

[Anonymous Coward]

Millions of 6502s made each year by various companies in hsinchu science park. The patents have expired after all.

I wish that was accurate

[Anonymous Coward]

I love assembler programming - in fact it was it was the second language I learnt after basic. If I could get a job in assembly* I would be in heaven. Unfortunately I've seen almost exactly zero evidence that this "trend" is real.

*x86 or z80 ideally, but I'm not fussy, and new processors aren't hard to pick up.

Re: I wish that was accurate

[Anonymous Coward]

new processors aren't hard to pick up

No shit. Their weight is measured in grams. An infant could pick them up.

Re: I wish that was accurate

[Anonymous Coward]

Their weight is measured in grams.

Grams are not units of weight.

Re: I wish that was accurate

[Anonymous Coward]

Lol

Re: I wish that was accurate

[Anonymous Coward]

I get what you are trying to say, but in common english usage, you say "how much does that weigh", not "what is that thing's mass" or "how many Newtons does that thing exert at sea level on Earth". People. Amirite?

Re:I wish that was accurate

[gweihir]

I strongly suspect the job ads counted are for "Assembler and C" or the like, never only assembler.

Re: I wish that was accurate

[Anonymous Coward]

> Grams are not units of weight.

True, but under stable conditions mass will correspond to weight.

My doctor puts me on a scale, and then writes "78kg" on the clipboard where it says "weight." He doesn't give a shit, obviously.

Re:I wish that was accurate

[thinkwaitfast]

seen almost exactly zero evidence that this "trend" is real.

Are you looking at programming jobs or electrical engineering embedded development jobs? This is kinda the thing that an EE does almost as an afterthought.

Re:I wish that was accurate

[thinkwaitfast]

There are many MCUs that do not have a C compiler.

Re:I wish that was accurate

[jrumney]

Many? Can you name 2?

Re:I wish that was accurate

[NixieBunny]

I program little tiny things that run on PIC16Fxxx processors, clocked at 32.768 kHz. C is not feasible for this environment. If you think no one uses this shit, ask the Woz what wristwatch he wears. http://www.nixiewatch.com/firm...

Re:I wish that was accurate

[jrumney]

You may not want to use C, but there are at least 4 compilers available for PIC16 devices, so it isn't really a good example of the "many" devices that do not have a C compiler, which the GP would have us believe is the reason for a sudden resurgence of interest in assembly language.

Just wait till web-assembly comes out ...

[Qbertino]

... or are they mixing assembly up with web-assembly?
That would explain a thing or two.

Objective-C

[Anonymous Coward]

Huge drop for Objective-C... 6 to 15

Re: Objective-C

[Anonymous Coward]

Probably bad news for Objective A and Objective B

Re: Objective-C

[Anonymous Coward]

They'll all end up forgotten in the ashcan of history, just like Preparations A through G. I'm holding out for Objective D or E.

Here's a top language too

[Anonymous Coward]

It's called bullshit

Groovy, Ruby, Objective-C

[Anonymous Coward]

The fact that assembly went up a bit isn't particularly interesting. The much bigger news, IMO, is that Ruby jumped up quite a bit, Groovy went way up, and Objective-C went way down. Groovy's vector really is quite impressive.

Re:Groovy, Ruby, Objective-C

[Anonymous Coward]

Objective-C went way down

That's unsurprising. Objective-C developers are switching to Swift.

Re:Groovy, Ruby, Objective-C

[Anonymous Coward]

Groovy is basically dead outside of Gradle. Hopefully Kotlin or any other JVM language will replace it. Groovy is so fucking bad and ridiculously slow.

Ahem

[kackle]

"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?"

A) Why don't you ask them and learn?

B) I politely disagree that they are automatically "far less productive". I am an embedded programmer and have only used tiny amounts of assembly over the last decade. However, if I had more tiny projects, and my bosses weren't akin to cats chasing flashlight spots to where I could stick with the same processor for more than a year, I'd consider it for sure. Why? Because I never seem to get to just "code and go" anymore. As an example, last week I had to reinstall my multi-gigabyte Eclipse IDE for the SECOND time this past year (this time due to a debugger corruption). In such IDEs, all the higher libraries (and their paths) need to be in place, and compiled too (which doesn't always go perfectly). Whereas my former officemate would open any text editor (his was Corel Word Perfect(!)) to write his assembly, then compile on the command line, then upload the binary.

I don't know how many hours I've spent learning and fixing IDEs. Then, a year to two later, the IDE changes again after the chip's OEM "upgraded" it! ...More productivity down the drain.

Re:Ahem

[lgw]

That's not a problem with "compiled code". That's the problem that Eclipse blows goats for crack. Switch to IntelliJ (or the other language products by the same guys) - still takes a while to load, but at least it won't corrupt itself.

Of course, Notepad++ is good enough for most simple C/C++ programs, or small bugfixes. Anyone recommend a decent Linux equivalent? And no, if I wanted VIM, I already have VIM, thanks.

Re:Ahem

[MillionthMonkey]

I always write assembly because it's easier to read than Perl.

Re:Ahem

[Anonymous Coward]

I don't know about word pervert, I always hated it. But my first programming experiences were using wordstar in non-document mode, sure. That was what that non-document mode was for. (Sitting in my room in the attic, using a Kaypro, keyboard sound turned off, late at night, glorious silence.)

I've heard on various occasions that even people forced to use windows for a text writing job are more productive when using their own favourite editor, like vi, then importing the result into the fancy wysiwyg thing supposed to be used, and finishing up with some formatting work. You too could install a fave text editor and use that. What's stopping you?

And yes, it's true that tech is pervaded by bloat. IDEs are a good example.

Re:Ahem

[BlackHawk-666]

"I''ve heard on various occasions that even people forced to use windows for a text writing job are more productive when using their own favourite editor, like vi, then importing the result into the fancy wysiwyg thing supposed to be used, and finishing up with some formatting work. You too could install a fave text editor and use that. What's stopping you?"

The 80s were over 30-35 years ago.

Re:Ahem

[Anonymous Coward]

Of course, Notepad++ is good enough for most simple C/C++ programs, or small bugfixes. Anyone recommend a decent Linux equivalent?

Sublime Text is the [proprietary] Linux equivalent of Notepad++. Geany is also fairly close but a bit lighter weight. Both worth checking out.

Re:Ahem

[Pikoro]

Notepadqq?

Re:Ahem

[Anonymous Coward]

The 80s were over 30-35 years ago.

You couldn't manage a more precise calculation? Despite the half-decade range you gave yourself, you didn't even come close to hitting your mark.

35 years ago, from your post, it was July, 9th, 1981. The 80's was just getting started! I'm pretty sure the 80's were still on-going.

30 years ago, from your post, it was also July 9th, 1986. The 80's were in full swing. A full month had not yet passed since the release of Ferris Bueller's Day Off.

Not only were the 80's still ongoing through your entire range in the temporal sense they were ongoing in the cultural sense!

There is no possible way to interpret your post in such a way as to make it either correct or coherent.

Re:Ahem

[NixieBunny]

I just started working on a job in Vivado, which is Xilinx's new development environment for their latest multi-thousand dollar FPGAs. The supplied editor does not know what VHDL is. I use Emacs to edit my source code, because it has a VHDL template processor. If only the people developing the latest IDEs had any idea what their customers actually did or a living...

Re:Ahem

[Anonymous Coward]

Sublime Text. There are also Windows and Mac versions, BTW.

Re:Ahem

[Anonymous Coward]

Of course, Notepad++ is good enough for most simple C/C++ programs, or small bugfixes. Anyone recommend a decent Linux equivalent? And no, if I wanted VIM, I already have VIM, thanks.

Under KDE, Kate is pretty decent. The Gnome equivalent, gedit, is much weaker. Vim is what I use, though. Not quite sure why, since I don't use it very well.

Re:Ahem

[thegarbz]

I agree with the premise but the IDE and the programming language are two different things. You can just as well code C++ in Corel Word Perfect and Assembly in Eclipse.

Re:Ahem

[angel'o'sphere]

B) I politely disagree that they are automatically "far less productive".
Nevertheless you are wrong, historically we distinguish between "(1) application programming", "(2) utility programming" and "(3) system programming".

The lines of code a programmer produces per day according to (old probably outdated) studies by IBM and the MIT are:
25 - 100 for (1)
5 - 25 for (2)
and less than 1 for (3)

And interesting point: regardless what programming language they use

Funnily 3 lines of Lisp do a magnitude more work/calculations than 3 lines of assembly.

Hence the higher level the language the higher the productivity in terms of "getting stuff implemented".

Re:Ahem

[Anonymous Coward]

You should have used Emacs.... *ducksforcover*

Re:Ahem

[KiloByte]

Hmm... let's compare some code written by a newbie, with comments that are of no use, with the asm equivalent.

Re:Ahem

[Luthair]

Eclipse even with a lot of add-ons isn't "multi-gigabyte" its not even nearly a gig, maybe you're putting a bunch of weird shit in it but that isn't in any way normal.

Re:Ahem

[Luthair]

Of course, Notepad++ is good enough for most simple C/C++ programs, or small bugfixes. Anyone recommend a decent Linux equivalent? And no, if I wanted VIM, I already have VIM, thanks.

Notepad++ runs under wine fairly well, otherwise maybe textadept? Someone spent time making Notepad++ compilable with gcc though I don't know that they got to the point of building on Linux.

Re:Ahem

[Luthair]

For me Kate has always felt pretty flakey, its like Notepad from Windows with a few more features but doesn't really have enough to be used regularly.

Re:Ahem

[Anonymous Coward]

Your reasons are invalid and quite frankly embarrassing.

1. A particular IDE is not reflective of the quality of higher level languages. I don't know if your company forces you to use a crappy IDE, but that in itself is not reflective of the language itself.

2. C/C++, Java, Go, etc. can be compiled on the command line just as your former co-worker would compile his Assembly so I have no idea why you thought this was even worth mentioning.

3. I politely disagree with your polite disagreement. For 99% of programming projects Assembly is unnecessary and an impediment to productivity. So you are wrong 99% of the time and correct 1% of the time. That's a pretty stupid approach to life and reasoning.

4. If you are making a point about programming, please do not refer to your co-worker that used a Word Processor for his code editor as an example of how to do things. *SHUDDER*

Re:Ahem

[Anonymous Coward]

The 80s ended when the 90s started, that was 26 years ago -- so good job on your maths.

Assembly? Oh no! Voldemort is back!

[Anonymous Coward]

People are going actually have to learn how to program a computer. The horror! What will happen to all the millennials now?!

Old farts to the rescue! Stand aside, kid. I'll fix it!

Oh, Assemblyman! How can we ever repay you?

Tune in next week, when COBAL battles the FORTRAN Godzilla in Silicon Valley..

Re:Assembly? Oh no! Voldemort is back!

[Anonymous Coward]

What will happen to all the millennials now?!

Their heads will explode when I try to explain pointers to them.

Re:Assembly? Oh no! Voldemort is back!

[Anonymous Coward]

People are going actually have to learn how to program a computer. The horror! What will happen to all the millennials now?!

There will be spawned hundreds of assemblers written in javashit that take the latest Intel XEON, 32 GB RAM and GPGPU code to make ROM images for the little 8bit CPUs running in your heated underwear.

Re:Assembly? Oh no! Voldemort is back!

[Koen Lefever]

COBAL battles the FORTRAN Godzilla in Silicon Valley..

Is COBAL a mix of COBOL and COMAL?

Said like somone who doesn't code in assembly

[Anonymous Coward]

Modern CPUs are complex beasts. The timing and pipelining of instructions makes it very difficult for a human to best-optimize their code, all while solving a much larger problem. And then there's the competency of the programmer to consider: An uber coder can do it, but your average programmer will spit out something that limps along. So unless you have a genuinely speed-dependent problem and are allocated a lot of money in your project budget to throw at that particular problem, let the compiler do it.

Re:Said like somone who doesn't code in assembly

[Gr8Apes]

but your average programmer will spit out something that limps along

This is true no matter the language. Copy-Paste from stackoverflow will never substitute for a real programmer

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:Compiling toothbrush code with GCC

[Guy Harris]

And, yes, there are people who want to hack their toothbrushes.

(For more fun, try a Web search for "toothbrush microcontroller" - that's how I found all those links.)

Re:Compiling toothbrush code with GCC

[ColdWetDog]

According to TFA, the electric toothbrush reference design is also suitable for 'personal care items'.

Never in a thousand years would I have thought such a stodgy outfit as TI would have ever created a reference design for a vibrator.

Not to mention the sad state of affairs when said vibrator needs a microprocessor. Now you have no idea with the thing is really doing when you turn it on. This is a really fucking weird world.

Re:Compiling toothbrush code with GCC

[tepples]

Without an MCU, how would an iBrator vary its rate in sync with the porno you're watching?

Re:Compiling toothbrush code with GCC

[Anonymous Coward]

Simple, just modulate the motor speed with the sound picked up by a small microphone.

Re:Compiling toothbrush code with GCC

[NixieBunny]

Finally, a thread about vibrator design!

Re:Compiling toothbrush code with GCC

[thegarbz]

So don't assume all the code in your toothbrush was written in assembler language

Actually my assumption is that my electric toothbrush doesn't have code at all.

Re:Compiling toothbrush code with GCC

[Anonymous Coward]

Is that toothbrush on the internet of silly things? I like the idea of hacking someone's toothbrush.

Re:Compiling toothbrush code with GCC

[Guy Harris]

Is that toothbrush on the internet of silly things?

Depending on the definition of "internet", this toothbrush might be. (It might not use the Internet Protocol running atop Bluetooth, but it does connect to a machine that probably is connected to the Internet.)

I like the idea of hacking someone's toothbrush.

That might be difficult if, as per the All About Circuits posting I referred to in a followup, there's a "code protection feature" in the microcontroller that makes it difficult if not impossible to overwrite the code. You might still be able to overflow a buffer and cause a return to code you supply, for example - if the microcontroller isn't a Harvard-architecture processor only capable of running code from code memory.

Re:Compiling toothbrush code with GCC

[Luthair]

Mine has a timer and talks to some base station. I've actually seen bluetooth models that talk to your phone, no clue why though.

PFFT! Assembly is NOT low level!

[Anonymous Coward]

Straight up binary is where the action is. Everything else is salad dressing...

Re:PFFT! Assembly is NOT low level!

[Anonymous Coward]

Real programers use: COPY CON: FOO.EXE

Re:PFFT! Assembly is NOT low level!

[fustakrakich]

01010011 01110100 01110010 01100001 01101001 01100111 01101000 01110100 00100000 01110101 01110000 00100000 01100010 01101001 01101110 01100001 01110010 01111001 00100000 01101001 01110011 00100000 01110111 01101000 01100101 01110010 01100101 00100000 01110100 01101000 01100101 00100000 01100001 01100011 01110100 01101001 01101111 01101110 00100000 01101001 01110011 00101110 00100000 01000101 01110110 01100101 01110010 01111001 01110100 01101000 01101001 01101110 01100111 00100000 01100101 01101100 01110011 01100101 00100000 01101001 01110011 00100000 01110011 01100001 01101100 01100001 01100100 00100000 01100100 01110010 01100101 01110011 01110011 01101001 01101110 01100111 00101110 00101110 00101110

The Slashdot filtering system prevents posting this without ASCII fluff that you are free to ignore...

Re:PFFT! Assembly is NOT low level!

[Anonymous Coward]

01010111 01101000 01100001 01110100 00100000 01100001 01100011 01110100 01101001 01101111 01101110 00100000 01101001 01110011 00100000 01110100 01101000 01100001 01110100 00111111 00100000 01000111 01101111 01101001 01101110 01100111 00100000 01101000 01101111 01101101 01100101 00100000 01100001 01100110 01110100 01100101 01110010 00100000 01110111 01101111 01110010 01101011 00100000 01100001 01101110 01100100 00100000 01110111 01100001 01101110 01110100 01101001 01101110 01100111 00100000 01110100 01101111 00100000 01100010 01101100 01101111 01110111 00100000 01111001 01101111 01110101 01110010 00100000 01100010 01110010 01100001 01101001 01101110 01110011 00100000 01101111 01110101 01110100 00100000 01101011 01101001 01101110 01100100 00100000 01101111 01100110 00100000 01100001 01100011 01110100 01101001 01101111 01101110 00111111 00100000 01001001 00100111 01101100 01101100 00100000 01101000 01100001 01110110 01100101 00100000 01110100 01101000 01100101 00100000 01110011 01100001 01101100 01100001 01100100 00100000 01100100 01110010 01100101 01110011 01110011 01101001 01101110 01100111 00100000 01110000 01101100 01100101 01100001 01110011 01100101 00100001

Years too late...

[__aaclcg7560]

I wanted to take assembly language in college. The dean wanted to teach the course. But I was the only student who showed up for the class. One student doesn't prevent a class from being cancelled. Since this wasn't a required course for graduation, I couldn't take it as a special studies project.

Re:Years too late...

[gweihir]

That is tragic. While rarely used, it gives you a far better understanding of how things work. Seems most engineering students these days aim for being mediocre.

Re:Years too late...

[Anonymous Coward]

I recently taught myself 8-bit PIC microcontroller assembly from an instruction set reference and the datasheet for the micro I was programming. If you still want to learn it, you certainly can.

I'm currently using a PIC16F18855 to interface between a serial port and a DC motor driver chip. It's quite fun.

What a bunch of Maroons

[Anonymous Coward]

Every CPU only executes "assembly code" (ie, machine code. It makes no difference whether it is a coffee pot, phone, PC, or even a supercomputer.

They all run machine code only, and the way to express machine code that is human readable is called Assembly Language.

If performance is key...

[Anonymous Coward]

... I wanna see a human beat any modern-day compiler to optimizations.

The other argument might be valid, but this one is not.

Re:If performance is key...

[Rockoon]

I wanna see a human beat any modern-day compiler to optimizations.

asmfish

10% to 20% faster than the C++ version.

The authors of the c++ version have attributed the speed gains to better register usage. The author of this asm version says he hasnt actually started optimizing yet.

You C++ programmers are delusional.

Re:If performance is key...

[Megol]

Yes it is. Even a skilled C/C++ programmer will not generally approach the performance of a skilled assembly language programmer, even when rewriting the C/C++ code to be closer to an optimized asm routine. Sometimes the differences are huge.

The C/C++ programmer can spend more time tweaking code as less effort is required for those high-level languages compared to assembly language. In some cases that mean the C/C++ code can be faster (by using a better algorithm) in practice.

Because Moores law is running out of steam

[Anonymous Coward]

3x faster than C, 10x faster than Java, many orders of magnitude more compact than either.

You don't use asm if you have choices, but if you have fixed hardware and still need more performance or more compact code there aren't any other good options.

Though Forth will give asm a run for it's money in some circumstances - the problem with Forth is the bills from keeping the programmers in a suitable frame of mind are probably excessive ;)

Re:Because Moores law is running out of steam

[Khyber]

Fuck FORTH and fuck Reverse Polish Notation.

Re:Because Moores law is running out of steam

[Luthair]

Isn't a lot of the compactness due to the compiler generating a number of code paths by CPU?

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:Horsecrap

[thinkwaitfast]

Most of the world is small and trivial applications. I suspect this is not due to speed or size but more that many of the processors and (sub)systems are not complex enough to support a C environment. I do mostly EE related work and not much CS and have worked with CPUs that could not address more than a few bytes of memory. C is not a option in these cases. Something like this.

Re: Horsecrap

[jrumney]

C is not a virtual machine. It doesn't have an environment on the target. Unless by environment you mean a stack, but I've even seen a subset of C used (carefully) on stackless embedded systems with RAM and ROM measured in bytes.

Re:Horsecrap

[thegarbz]

Indeed, compilers are far better than assembly righter for any [insert arbitrary condition to make the premise of this sentence true].

Now how many people code a large application in assembly? Very few. How good is a compiler at beating an assembly coder in most of the tiny applications which make up the majority of the world? Not very.

Re:Horsecrap

[Giant Electronic Bra]

In what world are 'the majority of applications' written in assembly language? This is the rankest fantasy. The vast majority of all applications are running on vast server farms in huge data centers. The other vast majority are running on desktops, laptops, tablets, and phones. Another vast category are running on relatively highly capable embedded devices that run on 32-bit microcontrollers, of which a PLETHORA exist based on either MC68k (FreeScale CodFire, Dragonball, etc), or various low-power iterations of ARM processors. The amount of stuff running on little 8 or 16 bit controllers is, in terms of running code and instructions actually executed, trivial. Yes, there may be zillions of copies of toasters and microwaves out there, but to imagine that they are 'most of the applications' running in the modern world is ludicrous.

Re:Horsecrap

[thegarbz]

In what world are 'the majority of applications' written in assembly language? This is the rankest fantasy.

As is you following my sentence which was a direct continuation of the size of projects you pointed out. But English is only my 3rd language so let me make it as clear as possible with only a single subject and no complicated sentence structures:

Assembly programmers can easily beat compilers in small applications.
Small applications make up by far the largest majority of the worlds applications.

Yes, there may be zillions of copies of toasters and microwaves out there, but to imagine that they are 'most of the applications' running in the modern world is ludicrous.

I disagree. Especially with the notion of zillions of copies. The reality is actually there are zillions of *different* copies out there locked at a single point in time. If you buy two identical devices out there there's a good chance they are not running the same code if they didn't come out of the factory at the same time. For each type of device there may be 10s of manufacturers with 1000s of different models running millions of different revisions, and god forbid you have something more complicated than a microwave .... actually no, scratch that. My microwave has 3 microcontrollers in it (found it out during a repair) so even that single device provides more variance than say a server farm crunching away with a huge problem on it.

You're dramatically under-estimating scale.

Re:Horsecrap

[Anonymous Coward]

sometime in the early 90's optimizing C compilers FAR outstripped hand-coded assembly for any larger project

Curiously enough, in the early 90's I was *routinely* outstripping the best optimizing compilers (a factor of 4x was rather common). And I'm not even a real programmer (like Mel). The size of the project does not make any significant difference, as most code is executed just once, or very few times. It has always the tight loops where most of the time is used (and often wasted), and this hasn't changed in the last 20 years, and I don't expect it will in the coming 20 either.

What optimizing compilers have definitely changed is our ability to write *crappy* C and have it run reasonably well. But I'm undecided if this has been a change for the best...

Re:Horsecrap

[Giant Electronic Bra]

I'm sorry, but its ridiculous to count Samsung Microwave model 333-X and 334-X, that run 95% of the same code and differ by one feature, and each factory rev of each one of those, which may differ by 0 or a few bytes of code as a separate program, that's preposterous. By that measure every single installed copy of the Linux OS is a separate program since they SURELY link to a unique subset of all the possible libraries out there, use different libc's, etc etc etc. This kind of counting is utterly bogus.
You have to understand that when you say "small applications" you are talking about a VERY VERY small class of applications, ones that compile to no more than at most a few 100 or perhaps 1000 bytes of code and contain a few hundred instructions. ANYTHING more extensive than that is not human-optimizable to the level that a compiler can achieve. Frankly its just infeasible and not cost-effective to attempt full hand optimization of larger code bases, and anything less will fall short of what the best compilers will do. Understand, I say this as someone who has written a great deal of assembly language code, assemblers, real-time applications and system code, etc. I also wrote FORTH compilers which performed both local and global optimizations on performance-critical code. I have a good idea how this stuff works, even if I'm not really involved in the area currently. I can certainly put out some VERY good MC68k code, but I know for a fact that the best commercial compilers, starting in the early 90's, began to exceed our ability to do it faster except in very small sections of code like interrupt handlers.
I worked extensively with PASC FORTH and OS-9/68k back in the day. We did lots of very cool stuff and a lot of that code (the entire OS and much of the compiler) were written in hand-coded assembler. Now, go look at the history of OS-9/68k, which is a high performance Posix-oid RTOS, and you will see that it was replaced in the mid-90's by OS-9000, which is entirely written in C, and was at the time equally fast, and is now MUCH faster (presumably, nobody even bothers with OS-9 anymore). I'd note that even in OS-9000 certain sections that handle clock ticks, basic interrupt controller handling logic, and some other bits ARE still assembly. Those are bits that are SMALL pieces of code where a human can consider every aspect of execution and, if you are a real deep subject matter expert on the specific architecture, eek out enough clock cycles to make it worthwhile. Other than that? You'd just make the bulk of the OS slower if you tried to code it in assembler.
I'd note that OS's like OS-9000 (things like VxWorks for instance) are embedded in all sorts of things. Many appliances, many commercial spacecraft, aircraft, industrial systems, etc. Truthfully, THESE are the super common things, because each one REALLY IS unique, or close to it.

Re:Horsecrap

[thegarbz]

Clearly you haven't pulled apart such a microwave. Not only would you realise that there's a good chance Model 333-X and 334-X run very different circuit boards with different uCs, Chances are the model 333-X and the model 333-X next to it do the same. Functionality is basic, coding is quick and easy and can be achieved by an undergrad in an hour. Standardisation on the small platforms has no economic value and locks your supply chain away from the cheapest devices.

You'd know this if you've ever tried to hack a piece of electronics only to find that you need Revision 0.1A of a board instead of the Revision 0.2F which you happen to have on your hands and is completely different.

You have to understand that when you say "small applications" you are talking about a VERY VERY small class of applications, ones that compile to no more than at most a few 100 or perhaps 1000 bytes of code and contain a few hundred instructions. ANYTHING more extensive than that is not human-optimizable to the level that a compiler can achieve.

I suppose you've never seen a large program then suddenly switch to inline assembly because the programmer wasn't able to get the compiler to bow to his wishes. Clearly you're not an embedded programmer and don't program for applications with hardware timers.

Re:Horsecrap

[Giant Electronic Bra]

Any given model and set of assemblies of a common household item is going to be produced in large numbers. Yes, in all, there are undoubtedly quite a few different variations of microwave oven, but as I explained before, calling that 'most of the applications in the world' is hardly meaningful. Any differences there are purely "we used the 82455 UART instead of the 82-C455 UART this time" which hardly matters. I will let you in on a little secret, a LOT of the code in those things isn't assembler, its PL/M or similar vendor-specific stuff. Much easier to code and frankly nobody gives a shit about the performance of microwave oven code as long as it works.

Every time you fly on a commercial airliner you depend on code I had a considerable hand in writing. I've written large pieces of assembly language code. I'd say if someone is 'dropping into assembler because they can't get the compiler to bow to their wishes' they are either a crappy programmer, or they have a compiler that sucks. If you're writing OSes and such then you DO sometimes have a need to write some assembly code, but its not because the compiler won't do what you want. I suppose there could be other cases, perhaps when accessing functionality that is very specific to certain hardware, or that is very new, etc, but I've rarely run into that kind of thing myself. Particularly in this day-and-age there are almost always good libraries that deal with most of those issues already.

cc65 doesn't optimize much

[tepples]

It's not unreasonable to imagine that the ongoing proliferation of embedded doodads would spur that on, but it's a stretch to imagine that it's for devices for which there is nothing but an assembler.

For systems using a 6502 family CPU, there is a C compiler. But it doesn't optimize much, and the 6502 architecture isn't well suited for efficient execution of C anyway. That's why even though a few modern-day NES games are written in C, most are written in assembly language.

Re:cc65 doesn't optimize much

[Anonymous Coward]

> and the 6502 architecture isn't well suited for efficient execution of C anyway

I don't think it's well suited for efficient execution of ANYTHING. :)

Re:cc65 doesn't optimize much

[Roger W Moore]

There is another reason: the 6502 assembler is relatively easy to program (I was doing it at ~13-14) and you get a very significant performance boost. Modern CPUs have complex pipelined architectures and for efficient, fast execution modern assembly requires hints etc. so the CPU can make effective use of pipelines etc. This makes it far, far harder.

Even with a CPU as old as DEC's Alpha back in the late 1990's I was astounded when DEC's C++ compiler produced faster code than I could with basic assembly. Once I saw the hints it added I was able to up my game and beat it slightly but the speed gain was nothing like as impressive as it was for the 6502 based BBC Model B plus it required far more effort e.g. knowledge of the CPU architecture etc.

Re: cc65 doesn't optimize much

[Anonymous Coward]

The speed up going from interpreted or tokenism BASIC was tremendous (Ã--100 or Ã--1000). Clearing a screen pixel by pixel with BASIC would take minutes. Assembler would do it in a flash.

Try something like run Conway Game of Life. Even a simple shape like the R-pentomino on a 160x100 grid would take 12 hours even with 6502 assembly. Don't even thing of trying to do the Mandelbrot set. On an 20Mhz 8086 PC it took less than 70 seconds using a VGA graphics card 320x200x256 and 8086 assembler. With a computer shader it takes less than 5 seconds even on a 1024x1024 grid.

Re: cc65 doesn't optimize much

[Roger W Moore]

Don't even thing of trying to do the Mandelbrot set.

I actually did that on a 6502 in BASIC (floating point in assembly was beyond me at the time) on a BBC Model B. I was a school kid and got the algorithm off the back of a maths brochure from Leeds University which had a picture of the set on the front. It used to take all night plus most of the following day to run and you could not really zoom in that much but it worked albeit rather slowly!

C++? In my 8-bit MCU? Get out of here

[tepples]

What you say may be true of x86, x86-64, ARMv4-7, and AArch64, which get the most attention from compiler authors. On an 8-bit microcontroller, assembly tuned specifically for a particular ISA's available addressing modes can handily beat C++. Some ISAs, such as 6502, prefer a set of parallel arrays instead of an array of structures.

Re: C++? In my 8-bit MCU? Get out of here

[Anonymous Coward]

Even braindead architectures like 8051 and pic have compilers. For stm8 the code is fairly decent. 6502 is not c friendly but g+ does have a compiler for it. On the other hand, 4bit cpus are assembly only and they are even cheaper.

Larger MCU for existing devices?

[tepples]

If you are on an 8 Bit MCU, speed is not that critical, or you would use a larger and faster MCU.

When you want to add a new feature to hundreds of thousands or even millions of devices in the field, have fun recalling them to install "a larger and faster MCU."

Re:Larger MCU for existing devices?

[gweihir]

You can update 8 bit MCU based devices in the field? If so, I am deeply impressed, because you seem to be able to do something nobody else can do.

Re:Larger MCU for existing devices?

[tepples]

You can update 8 bit MCU based devices in the field?

Yes, so long as field update was designed into the device. What do you think Game Paks for the Nintendo Entertainment System were? And with the chipset in NES clones long having been condensed down to an SOC, it could be thought of as a microcontroller.

More seriously, there's an adapter board for the NES called Hi-Def NES, designed by Kevin Horton. It ships as part of the Analogue Nt console or as a solder-in kit for a front- or top-loading NES. It contains an FPGA with two jobs: translating the NES's pixel output into an HDMI bitstream with a lag of less than 1 ms and running the on-screen display for adjusting the picture. The OSD's logic runs on a 65C02-clone core, and both the 65C02 and its program are part of the firmware that the FPGA loads when the system is powered on. And this firmware can be flashed by running a program on an NES flash cart.

Re:Larger MCU for existing devices?

[gweihir]

I see your problem: You are unable to generalize and think one specific highly untypical example is representative. No use arguing with you, you do not have what it takes.

Re:Larger MCU for existing devices?

[tepples]

I apologize for failing to anticipate the specific direction of generalization you had in mind. Could you clarify?

Re:Larger MCU for existing devices?

[jeremyp]

You don't seem to understand how it works. You made an assertion that you cannot update an 8 bit device in the field. All that is needed to prove your assertion false is one counter example. Temples provided that counter example.

In fact any device that can be programmed can be updated in the field provided there is a reasonable means of replacing the programming. e.g. replace an EPROM, have a firmware updater etc.

Why Unicode was cut from /. (5:erocS)

[tepples]

Say, when were we supposed to get unicode support?

As soon as it's possible to prevent all current and future directionality override control characters from fuccing with the layout.

The preferred form for making modifications

[tepples]

I think they're talking about projects whose source code is in assembly language, where a work's "source code" is defined as "the preferred form of the work for making modifications to it" (GPLv2, GPLv3). That is, something like the Pently audio player (which uses a preprocessor written in Python but is otherwise in 6502 assembly) or the video games RHDE: Furniture Fight and Nova the Squirrel .

Re: The preferred form for making modifications

[Anonymous Coward]

I think they have no f*king clue what they are talking about. Idiots hardly ever do.

. . . and yet Java is still king.

[Anonymous Coward]

In fact, Java is becoming more popular if the data is to be believed. Is Oracle paying attention? Likely not.

Re: . . . and yet Java is still king.

[Anonymous Coward]

well, the data is not credible. sorry.

Where is go?

[Anonymous Coward]

I'm surprised to see Rust on this list and not Go.

Explanation is bogus

[jrumney]

The only reasonable explanation for this is that the number of very small devices that are only able to run assembly code is increasing.

The smallest device I have written code for is a PIC with 512 bytes of RAM and 256 bytes of ROM. It had a C compiler. It is also lacking in connectivity for making trendy IoT devices. So what are all these devices that can only run assembly code?

I think a more likely explanation is that fad languages come and go, and now that globalization has driven the value out of programming, and kids are leaving the industry, they are mostly going, leaving only the languages that have stood the test of time behind.

Re:Explanation is bogus

[thinkwaitfast]

What would you do if your processor did not have a C compiler?

Re:Explanation is bogus

[jrumney]

I would pick a different vendor for the processor. Lack of a C compiler is going to be the least of your support worries.

Re:Explanation is bogus

[Casandro]

There are still 4 bit microcontrollers. Even if you can get a C compiler, the limitations will be so severe most of the time just writing assembler directly will be a _lot_ less work.

Also certain things like "long arithmetic" are actually simpler in Assembler. Or just try to add 2 1024 bit numbers in C. It's surprisingly difficult. On Assembler you can simply use the carry flags.

Re:Explanation is bogus

[jrumney]

There are still 4 bit microcontrollers.

Yes, but only in certain very simple, high volume applications that demand low operating power (as opposed to low standby power where modern 16 and 32 bit microcontrollers will suffice), and code is typically just carried over from one model to the next, needing very few assembly programmers to support it. So I don't think 4-bit microcontrollers is the reason for assembly programming suddenly being in demand again.

The long arithmetic example may be more likely, with all the BitCoin farms being built out in China, even if this is something that you do once and put in a library (or just use something like GNU MP to start with).

Re:Explanation is bogus

[Anonymous Coward]

What would you do if your processor did not have a C compiler?

Type the machine code in using a hex keypad and a seven segment display like we used to do in the old days.

Re:Explanation is bogus

[angel'o'sphere]

Download some of the min C compilers and adapt it to generate the code you need.

E.g.: http://bellard.org/tcc/

But if you google https://www.google.de/search?q... you find dozens.

Re:Explanation is bogus

[Anonymous Coward]

The smallest device I have written code for is a PIC with 512 bytes of RAM and 256 bytes of ROM. It had a C compiler. It is also lacking in connectivity for making trendy IoT devices. So what are all these devices that can only run assembly code?

Easy. If you don't know assembly, you can't really troubleshoot/debug whatever is going on with the PIC, can you? Wait until you have a non-trivial timing bug, and you see how fast a high-level debugger fails you and how fast you're plugging in a logic analyzer on the actual circuit and profiling the code that is actually executing, not whatever you did in C

Coding can be Fun

[djinn6]

A lot of comments talking about the speed of assembly, but if you enjoy puzzles like sudoku, coding up a small executable in assembly can be much more challenging and rewarding. You have to work with a large number of variables in your head, keep track of memory locations, remember how the system calls work, etc. Not great if you're just trying to get things done, but it's definitely a good mental exercise.

Retro computers

[ag0ny]

Then there's also the popularity of retro computers and consoles. There is an increasing number of indie/amateur developers developing for these machines as a hobby.

During the last few months I have been uploading my Z80 assembly code to GitHub myself (a game for MSX computers), and many other developers are doing the same.

that day when TIOBE dismantled itself

[Anonymous Coward]

finally! thank you.

if someone still thinks this index measures programming language popularity they must be delusional.

the only thing this index measures is how often search engines - mainly google - index the term "$lanuage programming". nice time series but useless in regards to anything programming language

Few actually understand how to do assembly

[perpenso]

People suck at macro optimizations in assembly. If your assembly program is more than 25 instructions, you're probably not going to do a better job than a compiler.

Good assembly language programmers are not trying to out-optimize the compiler at instruction scheduling. Good assembly language programmers are leveraging information that can not be communicated to the compiler.

Re:Few actually understand how to do assembly

[0111 1110]

Exactly. You don't normally write something in assembly for the sole purpose of beating compiler functions at their own game,. Although no doubt HLL-is-the-only-way people will continue to make this argument. There are often parts of library functions that can be left out in a particular application especially if it is going into an inner loop that will be executed a few million times. And such functions also don't always do *exactly* what you want. Sometimes it's worth building a hexagonal peg for a hexagonal hole rather than trying to make the square peg fit by pounding it in.

C/C++ can be written in arch specific way

[perpenso]

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.

Contrary to popular myth C/C++ code can be written in ways that favor one architecture over another. One reason to understand the architecture, assembly language, is to write better C/C++ code for your target.

And then there is debugging.

Re:C/C++ can be written in arch specific way

[K. S. Kyosuke]

That is, however, one step down from the level of knowledge required for actual programming in assembly.

Toothbrush? Coffee Machine?

[angel'o'sphere]

My 300Euro coffee machine runs no code at all.
Neither does my plastic tooth brush.

And by the way: Assembly is not a language. 68k Assembly might be one assembly language. x86 another one. Both have not much in common.

Re:Toothbrush? Coffee Machine?

[Anonymous Coward]

On the other hand, GAS (GNU assembler) supports many different instruction sets (X86, ARM, etc.).

Not every detail can be expressed in C/C++

[perpenso]

Where the good assembly language programmer beats the compiler is usually not in the instruction scheduling. It is more typically leveraging knowledge that can not be communicated to the compiler about the desired implementation. High level programmers are constrained by their respective languages. The assembly language programmer is not so constrained.

Furthermore the architectural differences are sometimes a bogus complaint. For example where I last wrote non-trivial amounts of assembly was to get a few more fps out of a couple of video games. This was only necessary for low end machines, not the most recent architecture. If my optimizations were not needed on the more recent architectures that was not a problem, those systems were just fine performance wise. FYI I benchmarked this assembly code over several generations of x86 architecture over the years. While the performance benefits of assembly decreased over the generations it was always still a win, I did not have to update it. However when the original architecture that needed the assembly was no longer a supported target I turned off the assembly and let the C/C++ implementation get compiled so that maintenance would be easier (i.e. I would not be needed).

Not one language

[Anonymous Coward]

This is a silly claim. Assembly is not a language, but a wole load of different languages. Knowing Z80 assembler wont get you far in programming 64 bit ARM systems. They are as different as Algol68 and Scala.

Re:Not one language

[Anonymous Coward]

yes but journalists and those using the TIOBE as their source of wisdom don't know that...

So?

[Anonymous Coward]

If anything, the possible gain are bigger now.

It's not rocket science!

[Xenna]

Perhaps THOBE is mistaking the fact the NASA put up the full assembly code for the Apollo 11 guidance computer on Github and the interest in that (6000+ stars) for a revival of the language instead of a historical artefact.

Check it out here and don't forget to start it, together we can confuse THOBE and make Assembly the #1 language of the world again! ;-)

https://github.com/chrislgarry...

Re:It's not rocket science!

[Anonymous Coward]

It's TIOBE, and how should NASA releasing some code skew the search results for "assembly programming"?

Re:It's not rocket science!

[Xenna]

"It's TIOBE, and how should NASA releasing some code skew the search results for "assembly programming"?"

Sorry, I'm wearing my contacts ;-)

Anyway, the Apollo source is in assembly code. Quite a bit of it in fact and it's popular, thousands of people starred it in a short period in Github.

So what if TIOBE sees a large increase in lines of assembly on Github and thousands of stars and oncludes that assembly language is making a huge come back?

(I don't know how TIOBE calculates its results, but there must be some reasonable explanation. I do a lot in IoT and I see absolutely no signs of assembly language suddenly becoming more popular)

Re:It's not rocket science!

[angel'o'sphere]

Interesting link!

Is TIOBE reliable?

[Anonymous Coward]

Judging from the fact that Assembly is in the top 10, I would think not.

Re:Is TIOBE reliable?

[Andreas Mayer]

Depends on what you mean with 'reliable'.

I'm sure the numbers are correct. But they only track what languages people talk about.
While popularity is one reason for people to talk about a programming language, there are many others.
Newer languages will get more traffic than older ones since people have more questions about them.
More complicated languages will get more traffic because people have more problems with them.
Also, the granularity sometimes seems off. Assembler is a good example: there really isn't a single assembler language; there are many different ones. How useful is it to lump them all together?

So this index does provide some interesting data, but you have to be careful when trying to draw any conclusions.

Assembler is good for certain things

[Casandro]

First of all, many, if not most, computers run software so trivial on microcomputers so small, installing a compiler for them would just be _way_ more effort than to just code to program in C. Typical examples are the microcontrollers in electric toothbrushes or other smaller embedded systems. It's hard to get your software running on a 4 bit microcontroller as modern C makes assumptions like having your memory addressible at a byte level.

Then there is another, in my opinion more important, point. Assembler is a great teaching aid. It shows you what the computer actually does. Understanding things like pointers is trivial in Assembler so you can learn a lot from it. Also in Assembler every control structure hurts, as you need to keep track of it yourself. This nudges you towards writing simpler code, away from thousands of nested if statements and functions with hundreds of lines. Those are desirable traits in all programming languages.

No language is suitable for everything, but most languages have at least one are where they are really useful.

Re:Assembler is good for certain things

[Anonymous Coward]

Surprisingly (or not), no one yet has mentioned that it is an assembly language that Knuth chose for his famous series of books on computer programming.

Why use an MCU in a synesthetic vibrator

[tepples]

Do you mean using ambient volume as a trigger, with some means of gain control to make activation independent of overall playback volume? This would perform very poorly, as it would react to room noises and react to noises in the soundtrack that aren't in sync with the action.

Better performing options need an MCU. One is for the video to encode vibrator instructions in audio steganography, which would need a DSP to extract. Another, as used in Teddy Ruxpin toys, is to encode timing on a separately transmitted channel. For a vibrator, this would probably be RF of some sort, such as Bluetooth.

Re:Why use an MCU in a synesthetic vibrator

[Anonymous Coward]

Wow, talk about complex solutions to nonexistent problems!

Just look at the history

[Lawrence_Bird]

to know it is a bullcrap index. 1986: Ada as #2. Really? Lisp as #3? Really? The world was COBOL and C back then with FORTRAN (caps then) and assembly thrown in. Was there hype around both Ada and Lisp? Yes, very much so. There wasn't even an official standard until the early 80s but Ada and Lisp were going to be "the future." Perhaps more believable is the 1991 #3 as that is when DOD briefly mandated Ada use.

To call either Ada or Lisp "popular" at any time is really a reach. Hype/astroturfing is not popularity. Even tracking "how to I learn ..." searches does not measure popularity. They are measures of interest. Popularity can only be based upon job requirements, number of projects, even (broadly) loc metrics. Popularity is reflected by use/consumption, not what is talked about.

popular: 1. liked, admired, or enjoyed by many people or by a particular person or group. 2. (of cultural activities or products) intended for or suited to the taste, understanding, or means of the general public rather than specialists or intellectuals.

Of def 2, substitute "general programmer" (ie, Java, C, C++) with 'specialists/intellectuals' being those involved with Haskell, D, etc.

Given the current state...

[Anonymous Coward]

...it's not terribly surprising that so many don't really know what programming really is. Programming is a (hopefully) logical description of the solution to a problem or a need. The language used is simply a tool. And once we had higher level languages to work with the process went something like this:

1) write program in language of choice (I still like FORTRAN, COBOL and Pascal, use the right tool for the job)
2) convert to assembly language appropriate for the machine (step one of the compile)
3) convert that to binary image (step two of the compile)
4) link that to the hardware (step three of the compile)
5) execute your runnable program on that hardware

For those of us that fingered in a program directly to memory using switches on the front panel, assembly languages (and then higher level languages) were a wonderful innovation. Or course, I'm relatively new to this stuff, I only started in the mid 70's. Since then the proliferation of languages and assorted tools has really made a mess of things. And the NIMBY thought process has really mucked things up rather badly. Don't like the way something works... don't try to fix it, just create a brand new something or another to replace it. There's a stellar XKCD to describe this: http://xkcd.com/927/

Old isn't always bad and new isn't always an improvement. Some change is good but change for the sake of change (most often the case) is rarely a good thing.

Reason to Code in Assembly: Security

[PeteJanda]

Joining this thread a bit late, but I thought I had to mention this.. Security hasn't yet been mentioned as a reason for using assembly. Let's say you need a hardened general computing device with a handful of basic apps running on it. Start with the device's BIOS, and then move on to HW components' firmware (e.g., SSD drive). Then audit the OS (e.g., minimalist version of a Linux distro), and finally begin coding the app(s) of interest with an assembly compiler you trust (not trivial!). Huge, inefficient undertaking... realistically one within the domain of only gov't entities. But this is unfortunately what is needed in today's era of compromised BIOS, firmware, operating systems and even compilers that automatically insert "beacons" and countless other crap. In 1985 my father threw an x86 assembly book on my desk after I complained I couldn't run Sierra's Kings Quest series on his rig optimized for AutoCAD with a Hercules monographics card (i.e., only CGA, EGA and VGA supported by Sierra). So I learned assembly, and it took me months to display my first pixel in "graphics" mode. Point being: going through this exercise, I was able to count and account for every byte in the .exe or .com executables.

microcontrollers in personal devices

[Anonymous Coward]

Without a microcontroller, how would it implement the TCP/IP stack needed to send user statistics to the central server to be data mined?

In Principle

[Giant Electronic Bra]

You're correct, C itself is simply a way to tell a compiler to generate SOME SORT of instructions that accomplish X. If X is possible in environment Y, then C COULD be used in that environment. Practically speaking you could take a compiler that targets your instruction set, use a libc version with that and a cstart.o with that which are tailored to the specific environment and do what you're suggesting.

Of course in some very resource constrained environments that MAY not be worth the bother, and optimizers are certainly less effective when they have very few options to choose between. It may also be that in many cases only a small subset of C constructs CAN be effectively translated to a really limited environment.

So, there's a SMALL set of cases where you may have no choice but hand assembling code. These are going to be extremely resource constrained. Things like embedded sensors that run on ambient power (thermal, vibration, etc) or the energy of a wi-fi signal they're picking up. This is where you get into nano-watt power budgets and 'processors' that have only a couple registers, a few dozen bytes of RAM, and a tiny amount of ROM. Usually their ONLY function is to do some Analog to DIgital conversion and dump the results in a fixed format to a radio or other similar interface. This kind of 'code' is really just replacing a bunch of custom fixed-function electronics with a very basic progammability for design flexibility reasons. No real decisions are made in code, etc. These days anything that incorporates any significant control laws, etc is going to be on a control system that's talking to such sensors, and that will be in 99.99% of cases at least a 16-bit controller. Heck, embedded military systems all went 32-bit 20 years ago now. These things are all programmed in PL/1, PL/M, ADA, or some other HLL.

There are people widely using assembly language

[Anonymous Coward]

Assembly language programming is still alive and in good health even for x86 processors.
And there are projects written entirely in assembly language. Get some links:

FASM assembler.
FASM clone for ARM.
Advanded RAD IDE for FASM. (and FreshLib portable library)
RWASA - High performance, scalable web server.
MiniMagAsm - Small content management system (CMS).
AsmBB - High performance lightweight web forum software.
Kolibri OS - small and very fast operating system with GUI interface

I am not counting the small exercise projects here and there. I am not counting mixed language projects where assembly language is used together with high level languages.

Re:There are people widely using assembly language

[asm.supermaster]

Assembly language programming is still alive and in good health even for x86 processors.
And there are projects written entirely in assembly language. Get some links:

FASM assembler.
FASM clone for ARM.
Advanded RAD IDE for FASM. (and FreshLib portable library)
RWASA - High performance, scalable web server.
MiniMagAsm - Small content management system (CMS).
AsmBB - High performance lightweight web forum software.
Kolibri OS - small and very fast operating system with GUI interface

I am not counting the small exercise projects here and there. I am not counting mixed language projects where assembly language is used together with high level languages.

The above is my post. I simply missed to login. ;) Some of the above projects are mine, some of other assembly programmers.
And if someone think assembly language is hard to code and support - simply look at the timeline of AsmBB. It has been written for a month in my spare time.
The timeline contains only 89 commits:

AsmBB timeline

Assembly is fast!

[pfg23]

"Premature optimization is the root of all evil." Said some sage. It was either Fred Brooks or Donald Knuth, I forget. Google it.

Re:Assembly is fast!

[asm.supermaster]

Most (not all) optimizations in assembly language make the code more simple and readable. But even non optimal assembly code is often faster than high level languages.

Strange results

[kavehmz]

TIOBE results doesn't makes much sense. They are using general web searching to rank their list. It seems Redmonk, http://redmonk.com/sogrady/201..., is more accurate which is basd on github and stackoverflow. I hope they also publish their new analysis soon.

Reversing

[Anonymous Coward]

Are you sure it is popular because people are coding in assembly, or is it popular because people are reverse engineering binaries? I do a lot of work reverse engineering x86, x86-64, arm, powerpc, and mips binaries so I have to know all of those languages. Doesn't mean I code in them.

Assembly is, by definition, the only language...

[Anonymous Coward]

that lets you do ANYTHING the machine is capable of doing, with maximum resources and performance.

All other languages compile down to assembly at some point and are therefore not capable of better performance, and anything you do in any other language can by definition be done in assembly, including object-oriented and structured coding.

Languages other than assembly provide the benefit of ease for programmers, allowing them to trade run-time benefits for greater programmer productivity. There is, by definition, no way for a high-level coder to beat the run-time performance of assembly or reduce the resource requirements below those of assembly. Assembly is perfectly readable and maintainable to those who code in it, but less easily portable.

0days

[CODiNE]

Haven't seen it mentioned yet. Another reason to learn assembly (why I am right now) is for debugging closed source apps to earn bug bounties.

You have a few different groups of apps to target, with different rewards and challenges.
Web apps, open source apps, closed source programs.
Looking for bug bounties, the first pays less and there's tons of people looking for the same bugs. The second group is usually not going to pay unless you're looking at the Linux kernel or a specific server. You can use many source code analysis tools on these. The closed source apps are where the real money is at. Browser escapes, media player RCE, OS exploits, you'll need assembly skills to debug these and see what's going on internally. This is where you find $100,000 bug bounties.

Your honor, I rest my case

[Anonymous Coward]

You have just admitted that standard C cannot do these things, so there are work-arounds to permit people to revert to chunks of assembly inserted into their C code.

Those of us who have written tons of embedded code know this of course, but many coders who work on the PC or Mac and mostly write big applications in high-level code, sometimes having a fear of the voodoo called "assembly language", do not seem to know it. I guess most CS programs do not teach this stuff these days?

Incidentally, some C compilers seem to do the work-around like you cited, sort of faking CPU registers to be C variables and then handling them with C syntax, and sometimes requiring inefficient things like binary operators deal with things like the SR and Z,C,S and V flags, there are some that just provide a mechanism to just blatantly type native assembly right into the code of a standard C function wrapper.

It does not really matter if you kluge-in some assembly or if you hack-in access to registers and bits, it's all just an indirect admission that there are things you sometimes need to do on the hardware that the high-level language cannot natively do, but that can easily be done in assembly.