If your goal is to compile your own code and look at the dissassembly with objdump, take a look at the -S argument in objdump (I think it also requires that the code was compiled with -g to include debug information in the binary). It will display the C source code mixed with the generated assembly and it makes it a lot easier to understand what is going on, especially for more complex code that may have been agressively reorganized and optimized by the compiler.
This is a really interesting use case of Ghidra I've found. I can compile a C program to some target I'm not familiar with, then let Ghidra refigure out the C code, and let me highlight that C code so it can show me the relevant assembly.
I learned 6502 assembler 40 years ago and suspect that Acorn was influenced by the 6502 when creating the ARM architecture. Although I don't know much about x86-x64 assembler, ARM assembler appears more elegant to me.
The first instruction of the function at the start of the video is an STP (store-pair) with post-decrement of a stack-pointer relative addressing mode. That's how AArch64 spells "push", of two registers at once. It doesn't have a push instruction because it doesn't need one. STP/LDP keep the stack 16-byte aligned. As for later in the function, you want random access to your local variables in your stack frame, not push / pop.
Hi LLL! First of all, amazing video series! Keep doing this work. I really appreciate a lot. I've a doubt that goes beyond the context of this video. On 860 dump line, the instruction "mov w0, #0x539 //#1337" translates to 4-bytes hex representation of machine code 5280a720. Wow! That's crazy! How the number 1337 is stored in this hex representation? I think maybe this is a topic for another video. Tks.
Good question! If you think of instructions as a field of bits, the developers of the instruction set architecture decide what bits carry what information about the instruction. In this mov instruction, the value to be moved is shifted left by 5 to put it in the correct field of the instruction. 0x539 left shifted by 5 (which is the LSB bit position of the value for the mov instruction) is 0xa720, which is right there in plain view.
Hi ! What command did you use to convert the c program to assembly? I tried with objdump as well as gcc but in the MOV instructions, i dont get the hex representation of the letters. Instead, i get output like this "mov %edx,-0x4(%rbp)". So how did you convert it to assembly? Thanks in advance :)
At a guess, the sound hardware will receive input by being mapped in memory somewhere. Exactly what it needs to receive to output sound, will be hardware specific. It will be some sort of encoding of instructions and data that the sound hardware understands. Chances are though that all this will already be dealt with in drivers or other abstractions, so probably there will be some functions you can call from assembly much like the putchar in this example. i.e. put the data into the right registers or onto the stack then call the function.
If your goal is to compile your own code and look at the dissassembly with objdump, take a look at the -S argument in objdump (I think it also requires that the code was compiled with -g to include debug information in the binary). It will display the C source code mixed with the generated assembly and it makes it a lot easier to understand what is going on, especially for more complex code that may have been agressively reorganized and optimized by the compiler.
Good to know
This is a really interesting use case of Ghidra I've found. I can compile a C program to some target I'm not familiar with, then let Ghidra refigure out the C code, and let me highlight that C code so it can show me the relevant assembly.
A good demonstration how "Low Level Learning" can lead to buch better and HIGHER UNDERSTANDING! THANK YOU! :) I always love videos like this.
6:04 high pitch sound begins
Clear explaination ❤ More videos on aarch64 assembly deep dive and baremetal programming.
Thanks a lot
I learned 6502 assembler 40 years ago and suspect that Acorn was influenced by the 6502 when creating the ARM architecture. Although I don't know much about x86-x64 assembler, ARM assembler appears more elegant to me.
What's interesting is that the C compiler doesn't seem to use the stack as a stack. like no push or pop. Why is that?
The first instruction of the function at the start of the video is an STP (store-pair) with post-decrement of a stack-pointer relative addressing mode. That's how AArch64 spells "push", of two registers at once.
It doesn't have a push instruction because it doesn't need one. STP/LDP keep the stack 16-byte aligned.
As for later in the function, you want random access to your local variables in your stack frame, not push / pop.
Hi LLL! First of all, amazing video series! Keep doing this work. I really appreciate a lot. I've a doubt that goes beyond the context of this video. On 860 dump line, the instruction "mov w0, #0x539 //#1337" translates to 4-bytes hex representation of machine code 5280a720.
Wow! That's crazy! How the number 1337 is stored in this hex representation? I think maybe this is a topic for another video. Tks.
Good question!
If you think of instructions as a field of bits, the developers of the instruction set architecture decide what bits carry what information about the instruction. In this mov instruction, the value to be moved is shifted left by 5 to put it in the correct field of the instruction.
0x539 left shifted by 5 (which is the LSB bit position of the value for the mov instruction) is 0xa720, which is right there in plain view.
Where can I find the software tool that shows C code and its compied assembly code at the same time as the video?
This would probably been easier if you used Compiler Explorer.
Hi ! What command did you use to convert the c program to assembly? I tried with objdump as well as gcc but in the MOV instructions, i dont get the hex representation of the letters. Instead, i get output like this "mov %edx,-0x4(%rbp)". So how did you convert it to assembly? Thanks in advance :)
How audio output implemented in assembly language?
At a guess, the sound hardware will receive input by being mapped in memory somewhere. Exactly what it needs to receive to output sound, will be hardware specific. It will be some sort of encoding of instructions and data that the sound hardware understands. Chances are though that all this will already be dealt with in drivers or other abstractions, so probably there will be some functions you can call from assembly much like the putchar in this example. i.e. put the data into the right registers or onto the stack then call the function.
There's a objdump flag called -S, which can print the generated asm of each line
I am in love with this video.
Superb explanation. Thanks!
Shout out to all those who almost maxed their volume to hear and then got hit with an advert XD
Nice! I like it! Excellent click-bait title too.
Spectacular.
Is it ghidra?
11:34 forgot to cut that out huh ahah
thx!
An easier way is to compile to assembly, isn’t it?
It's not really the same, with the technique showed here we can also see the machine language.
What if
You wanted to go to Heaven
But God said
"Error: Constant cannot be expressed as 8-bit rotatable"
Amazing tutorial. I was wondering but do you use discord or something for contact?
I don't, maybe soon!