You guys still use assembly when programming these days?
Yep. Embedded systems with real-time interrupts and ISRs to keep up. You?
Good to hear that. :)
I used it a lot in my c64 days and later with my 80386 pc. (That were the days.... -sigh-)
Now I unfortunately do not program anymore.
Get back into programming, it’s still fun.
Check out the Processing.org website and download its IDE. It comes with a lot of support for writing processing based java programs that can do some cool graphics to amaze your friends and kids.
Not very often, but sometimes when I'm profiling I see a chunk of code that I know will be faster if I just convert it to assembly.
If you get into learning C code then You can experience the thrill of coding in something that can closely map to assembler without falling into assembler.
There's also the thrill of using Forth and its stack based programming paradigm which while not assembler is quite challenging to play with.
Personally, I'd try the Processing route first.
Hmm, I wonder if we need a new thread on "How to Write Excellent Assembly Language Code"....
Due to legacy issues, a lot of IBM mainframe financial based programs are a mix of Cobol and assembly (HLASM - high level assembler). One of the original reasons for assembly is that the database type interfaces like ISAM (indexed sequential access method) were assembly macros, but then shops started using assembly for speed. Few organizations are going to risk re-writing fairly large libraries of assembly code, so it remains.
As already posted, some aspects of operating systems, such as context switching, interrupt handling, are written in assembly.
Which one can do relatively easily by using assembly code embedded in C or C++ code. I use MSFT Visual Studio, which supports embedded assembly in 32-bit code, but doesn't allow it in 64-bit code. The workaround is to have a separate assembly file that gets assembled and linked to the rest of your code.
Not too many years ago I saw some assembly code in Windows video drivers, an obvious effort to speed up how pixels are updated as quickly as possible. I've also seen some assembly code using MMX extensions that was used in processing audio streams.
There are some specially tuned examples of assembly code, like this 600+ line assembly code for fast crc16 or crc32:
Modern compilers produce very effective machine code.
Only in the case of writing drivers for unique hardware could human written machine code be an improvement.
Surprisingly, still quite decent amount of effective run-time belongs to code made in assembly (on PC).
The reason is simple. It is known that most run-rime actually belongs to a relative small amount of code. To identify the problems with that small code is not a hard task: that's what profilers are about.
But once somebody wanna' make that small part faster, then there is just one tool left - assembly.
So at the end, the core of almost every CPU intensive code contains assembly. And when your game is running, 90% of the load generated by the 3D engine will run on assembly. When you render something, it's the same. Convert some videos? That's the same too.
Agreed, but not always the most effective code.
This is not the only case, as @Rive points out below.
Good programmers decide on the best tools for the job.
What I generally do when I program these days, as well as programmed professionally for over 30 years, is program in the language that's easiest to write in, and have a look at how fast it runs.
If its fast enough - great - you have done your job or exercise or whatever you wanted to do.
But sometimes it isn't. Then you go to the next fastest language for key parts. Still not good enough - then the next fastest and so on. Until finally you are forced to write assembler - but you try to avoid it like the plague because its not portable and has to be written for each platform. Sometimes though you really have no choice. For example the person that wrote the Lua Just In Time Compiler (LUAJIT) achieved considerable gains by doing it in assembler even though you need a version for each CPU.
I actually am sick of programming these days, but do it every now and then.
Here is what I do:
1. I write in Python because of its many features and packages like NumPy. If that is fast enough - well and good.
2. If its not fast enough I then write parts in LUAJIT. LUAJIT is sort of pythons secret weapon,
Personally I use Moonscript to generate LUA. I also write my own C wrapper whenever I call Lua from Python.
3. Note from the above link you see generally LUAJIT is as fast as C so it nearly always is all you need. If I want to go faster again I write C that includes inline assembler and write C wrapper code to call it from JUAJIT. Personally unless you want the speed of assembler I wouldn't use C because of how fast LUAJIT is, but like the person that actually wrote JUAJIT found out occasionally you need to do it.
You over time get a feel for the best tool - you may skip the Python and go straight to Lua and Moonscript - the choice really depends on if you need the packages in Python.
That's how I do it. So yes you occasionally use assembler - but rarely.
Modern compilers are indeed quite good and can produce code which usually are more optimal than an assembly code written by any average programmer.
That's a good reason for not using assembly if possible.
Separate names with a comma.