Is assembly language still being used?

[david2]

You guys still use assembly when programming these days?

 

[berkeman]

Yep. Embedded systems with real-time interrupts and ISRs to keep up. You?

 

[david2]

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.

 

[jedishrfu]

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.

 

[newjerseyrunner]

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.

 

[jedishrfu]

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.

 

[berkeman]

Hmm, I wonder if we need a new thread on "How to Write Excellent Assembly language Code"...

https://www.physicsforums.com/threads/what-should-be-the-rules-to-write-excellent-code.941950/

 

[rcgldr]

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.

 

[Mark44]

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.

 

[rcgldr]

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

 

[rootone]

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.

 

[Rive]

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.

 

[Mark44]

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.

 

[bhobba]

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

 

[Rive]

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...

 

[sysprog]

Much of IBM mainframe system source code is PL/S, which allows inline assembly code and direct access to registers. For a long time IBM would not release the compiler for PL/S to customers. Recently, they have relented, to the extent that under certain conditions, a registered development partner can get acess to it.

In the meantime, almost all system code for the IBM mainframe that is written outside of IBM is written entirely in assembly language.

As a registered IBM development partner, I'm probably eligible to get a copy of the current PLS compiler; however, I haven't applied for it, and don't intend to, because I want any source code that I deliver to be usable by and modifiable by any IBM mainframe shop. Any source code of mine that I retain and deliver only assembled object code from, I am apt to write in assembly language, for many reasons, not the least of which is that there is less likelihood of encountering dependencies.

If I want the advantages of a high-level-language, I can use PL/I, and in that language, I can call an assembly language subroutine: DCL ASMSUB1 EXTERNAL ENTRY OPTIONS (ASM, INTER, NOMAP); $-$ that declaration allows me to reference a separately assembled routine, in this instance called $\mathtt{ASMSUB1}$, that is by the PL/I compiler given a $\mathtt{VCON}$ placeholder, which is resolved by the linkage editor when the complete module is built.

I wouldn't do that in e.g. a system exit or front-end routine $-$ it's easier to write in assembler $-$ there are macros that map the control blocks, and I can chain through them to find what I'm looking for $-$ it's pretty similar to following pointer chains in C $-$ if I don't need efficiency, and it's not going to be part of the system, I'm apt to write it in REXX (a scripting, usually interpreted (but also compilable) language) , but if I'm coding a USERMOD (SMP/E term), it's in assembly language.

Yes, we still use assembly language, especially for system code.

A to-me-interesting project is a fork of the Stockfish chess engine to re-write it in assembler, the original having been written in C++ $-$ the C++ code makes for very instructive browse reading $-$ many advanced techniques . . .

From https://www.chessprogramming.org/AsmFish:

​

asmFish,​

a port of Stockfish in x86-64 assembly by https://www.chessprogramming.org/index.php?title=Mohammed_Li&action=edit&redlink=1, optional using AVX2 and BMI2 instructions, assembled with FASM to run under Windows or UNIX/Linux, first released in June 2016. The fun project is about to demonstrate how an experienced assembly programmer can optimize a program compared with GCC [2]. A few structural optimizations were also applied, such as elimination of piece lists as already tried in Stockfish [3], which were later reinstalled due to the slower but stronger pedantFish (asmFish with PEDANTIC = 1) with the same node counts as Stockfish, became default [4]. Critical functions in asmFish were not conform to the x86-64 ABI concerning register usage and calling convention [5]. Some less time critical code was ported using GCC generated assembly output, such as Ronald de Man's probing code for Syzygy Bases. asmFish further supports large pages, and its parallel search is numa aware [6] .​

​