- #1
david2
- 35
- 84
You guys still use assembly when programming these days?
Is assembly language still being used?
- Thread starter david2
- Start date
Click For Summary
Discussion Overview
The discussion revolves around the current use of assembly language in programming, exploring its relevance in various contexts such as embedded systems, performance optimization, and legacy systems. Participants share personal experiences and perspectives on when and why they might resort to using assembly language today.
Discussion Character
- Exploratory
- Technical explanation
- Debate/contested
Main Points Raised
- Some participants still use assembly language for embedded systems, particularly for real-time interrupts and ISRs.
- Others reflect on their past experiences with assembly language, noting nostalgia for earlier computing days.
- A few participants mention using assembly for performance profiling, indicating that certain code segments can be optimized by converting them to assembly.
- There are discussions about the effectiveness of modern compilers, with some arguing that they produce efficient machine code that often surpasses hand-written assembly.
- Some participants highlight the necessity of assembly in specific contexts, such as writing drivers for unique hardware or optimizing CPU-intensive code.
- Legacy systems, particularly in IBM mainframes, still rely heavily on assembly language due to the challenges of rewriting large codebases.
- One participant discusses a multi-language approach to programming, where assembly is used only when absolutely necessary, often as a last resort for performance gains.
- There are mentions of inline assembly in high-level languages like PL/S and the implications of using assembly for portability and dependencies.
Areas of Agreement / Disagreement
Participants express a range of views on the necessity and practicality of using assembly language today. While some agree on its continued relevance in specific applications, others argue that modern compilers often negate the need for assembly. The discussion remains unresolved regarding the overall necessity of assembly language in contemporary programming.
Contextual Notes
Participants acknowledge various limitations, including the dependency on specific hardware, the challenges of maintaining assembly code, and the effectiveness of compilers in generating optimized code. These factors contribute to the nuanced views on when assembly language should be used.
- #2
berkeman
Admin
- 69,479
- 25,004
Yep. Embedded systems with real-time interrupts and ISRs to keep up. You? 
- #3
david2
- 35
- 84
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.
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
jedishrfu
Mentor
- 15,681
- 10,475
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.
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.
- #5
newjerseyrunner
- 1,532
- 637
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
jedishrfu
Mentor
- 15,681
- 10,475
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.
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.
- #7
berkeman
Admin
- 69,479
- 25,004
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/
https://www.physicsforums.com/threads/what-should-be-the-rules-to-write-excellent-code.941950/
- #8
rcgldr
Homework Helper
- 8,948
- 687
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.
As already posted, some aspects of operating systems, such as context switching, interrupt handling, are written in assembly.
- #9
Mark44
Mentor
- 38,106
- 10,660
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.newjerseyrunner said:
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 said:
- #10
rcgldr
Homework Helper
- 8,948
- 687
There are some specially tuned examples of assembly code, like this 600+ line assembly code for fast crc16 or crc32:Mark44 said:
https://github.com/01org/isa-l/blob/master/crc/crc16_t10dif_01.asm
- #11
rootone
- 3,398
- 945
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.
Only in the case of writing drivers for unique hardware could human written machine code be an improvement.
- #12
Rive
Science Advisor
- 3,365
- 2,915
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.
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
- #14
bhobba
Mentor
- 11,001
- 3,855
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
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:
- #15
Rive
Science Advisor
- 3,365
- 2,915
Modern compilers are indeed quite good and can produce code which usually are more optimal than an assembly code written by any average programmer.rootone said:
That's a good reason for not using assembly if possible.
However...
- #16
sysprog
- 2,617
- 1,793
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:
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:
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] .
Last edited: