[Myrddin]

Real time embedded stuff tends to be built on top of APIs such as PSOS or VRTX. That gives you the ability to have multiple "tasks" with hard real time and pre-emption. It doesn't make sense to keep reinventing that wheel each time. There is a place for writing assembler to manipulate device registers and performance of "atomic" operations such as "test and set" cells that guard a common resource.

Current high performance processors depend upon a pipelined execution queue. Optimized compilers can create better "pipeline" code than most "skilled" programmers in assembler. A pipeline stall created by a careless choice of operations will trash the execution performance on that kind of CPU.

[mikegi]

Current high performance processors depend upon a pipelined execution queue. Optimized compilers can create better "pipeline" code than most "skilled" programmers in assembler. A pipeline stall created by a careless choice of operations will trash the execution performance on that kind of CPU.

Back in the old days it was easy to beat a compiler. Nowadays, it's much more difficult. Plus, CPUs are so fast that it makes no practical difference in most cases. However, there are a few applications where it still makes sense to use asm. For example, crunching large bitmaps. Compilers seem to have trouble with the nasty bit fiddling you do when crunching bitmaps.

[IronJack]

a pipelined execution queue.

I'm not sure what you mean by that. But whatever the code is, it ultimately becomes machine language. I've always wondered why the executable wasn't written in the language the machine speaks to begin with.