One thing is reading assembly language written by a human, another thing is reading assembly language generated by a compiler. Compilers are insane, especially when you turn on optimizations.
Another thing is that there is more than 1 asm syntax. Popular ones are the Intel syntax and the GNU assembly syntax. The way you read those is different.
If you want to get started in a simple way with little friction I suggest you do this.
1. Go to godbolt.org (Compiler Explorer)
2. Write a simple function (not program, that will complicate things), such as one with no parameters that adds two hardcoded. Like this
int sum() {
int result = 0;
result += 1;
return result;
}
3. Compile with with no optimizations (-O0).
4. Read the output. Note that the colors represent each statement. Pay attention to that. Also, by hovering over an instruction for a few moments you can get a definition of what it does.
Then you can start making adjustments such as using parameters, adding control flow like if statements, invoking other functions, using float instead of int, etc.
Another thing are calling conventions. Functions do not exist in assembly, they're an abstraction. There are many ways to represent a function call and these are some of them:
(Edit: I just noticed (yes, I am slow) that you were probably referring to code written by a human for educational purposes. Sorry for the misunderstanding)
> One thing is reading assembly language written by a human, another thing is reading assembly language generated by a compiler. Compilers are insane, especially when you turn on optimizations.
In my experience, it's the opposite. Compiler-generated code has a very homogeneous global structure that is easy to understand even if the compiler does complex stuff on instruction level. Human-written code does things that force me to be permanently on my guard concerning the control flow and the meaning of data, and I am not even talking about code (like malware) designed intentionally to be confusing. Examples from computer games:
- Calling a function X and directly wanting to jump to another function Y afterwards by first pushing the address of Y on the stack, then call X. Sometimes combined with a jump into the middle of another function.
- Manipulating stack frames, accessing local variables of the caller function, etc.
- Using the same location in memory to store completely different data types (imagine a C program using unions everywhere, even for a simple counter variable)
- Organising data on bit level
- Something extremely popular in older games: Collection types with non-uniform elements. Imagine a kind of array or list where some elements are 4 bytes long and some are 6 bytes.
Something extremely popular in older games: Collection types with non-uniform elements. Imagine a kind of array or list where some elements are 4 bytes long and some are 6 bytes.
There's this really funny reaction from the audience when Mike Acton suggests writing different types of scene graph nodes to a void* to avoid unnecessary padding which would pollute the data cache. One of the Q&A questions at the end utters its distaste for it cause it's using void instead of proper types.
It's the objectively better solution in terms of performance, but it's just too yuck for many people.
-O0 is unnecessarily bloated (can do lots of unnecessary load data to reg, save to stack, load back same reg again) which also makes it hard to read.
I find -Og (on gcc) or -O1 to be the sweet spot.
Compile factorial with avx enabled and the compiler will often go mad and shit out a 150 instruction body when n=low overflows and thus invokes undefined behaviour anyway
Another thing is that there is more than 1 asm syntax. Popular ones are the Intel syntax and the GNU assembly syntax. The way you read those is different.
If you want to get started in a simple way with little friction I suggest you do this.
1. Go to godbolt.org (Compiler Explorer)
2. Write a simple function (not program, that will complicate things), such as one with no parameters that adds two hardcoded. Like this
3. Compile with with no optimizations (-O0).4. Read the output. Note that the colors represent each statement. Pay attention to that. Also, by hovering over an instruction for a few moments you can get a definition of what it does.
Then you can start making adjustments such as using parameters, adding control flow like if statements, invoking other functions, using float instead of int, etc.
Another thing are calling conventions. Functions do not exist in assembly, they're an abstraction. There are many ways to represent a function call and these are some of them:
https://en.wikipedia.org/wiki/X86_calling_conventions