Is assembly language still being used?

  • Thread starter david2
  • Start date
  • #1
18
55

Main Question or Discussion Point

You guys still use assembly when programming these days?
 

Answers and Replies

  • #2
berkeman
Mentor
57,294
7,275
Yep. Embedded systems with real-time interrupts and ISRs to keep up. You? :smile:
 
  • #3
18
55
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.
 
  • #4
11,687
5,257
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.
 
  • Like
Likes david2, QuantumQuest and berkeman
  • #5
1,516
617
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.
 
  • #6
11,687
5,257
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.
 
  • Like
Likes QuantumQuest
  • #8
rcgldr
Homework Helper
8,682
520
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.
 
  • Like
Likes jedishrfu and QuantumQuest
  • #9
33,501
5,189
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.
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.

As already posted, some aspects of operating systems, such as context switching, interrupt handling, are written in assembly.
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.
 
  • Like
Likes QuantumQuest
  • #10
rcgldr
Homework Helper
8,682
520
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:

https://github.com/01org/isa-l/blob/master/crc/crc16_t10dif_01.asm
 
  • Like
Likes QuantumQuest
  • #11
3,379
942
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.
 
  • #12
1,596
944
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.
 
Last edited:
  • #13
33,501
5,189
Modern compilers produce very effective machine code.
Agreed, but not always the most effective code.

Only in the case of writing drivers for unique hardware could human written machine code be an improvement.
This is not the only case, as @Rive points out below.

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.
 
  • #14
9,369
2,422
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,
http://alexeyvishnevsky.com/2015/05/lua-wraped-python/
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.

Thanks
Bill
 
Last edited:
  • Like
Likes berkeman
  • #15
1,596
944
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.
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.

However...
 

Related Threads on Is assembly language still being used?

  • Last Post
Replies
13
Views
1K
  • Last Post
Replies
5
Views
3K
  • Last Post
Replies
18
Views
8K
  • Last Post
Replies
4
Views
985
  • Last Post
3
Replies
60
Views
14K
  • Last Post
Replies
3
Views
2K
  • Last Post
Replies
16
Views
740
  • Last Post
Replies
5
Views
3K
  • Last Post
Replies
18
Views
5K
  • Last Post
Replies
12
Views
2K
Top