 Climb and the sky grows. Hitch down doesn't work, right? I will introduce myself. I'm a system software engineer and I like diving into the technologies related to computer infrastructure such as operating system kernel and debugging and etc. Since I'm not a native English speaker so please excuse me for my poor oral speaking. I will go through these tips quickly and if I have another time I will show some code. Firstly, it's about the andiness. The andiness, the CPU generally has two kinds of andiness. First is the big andiness. For example, the spark CPU. I'm not sure whether how many people heard about the spark. For the big andiness, the most significant bit, 0A will be stored in the lower address of the memory. For example, A, A plus 1, plus 2, the 0A will be stored here. For the little andiness, I think the x86 is our most familiar CPU and it's the little andiness. It means the least significant bit, let's say 0D, will be stored in the lower address of the memory. Then 0C, 0B, and 0A. The other tips is about the byte alignment. Some CPUs, especially the RISC structure, RISC architecture, like Spark, it requires the straight byte alignment. That means, for example, if for the short integer who says it's only two bytes, the begin memory address will be the multiple of two. If it's integer who says it's four, under the star address must be the multiple of four. If the date is not byte alignment, the program will crash. On Spark, it will contain bus error. But for x86, maybe not byte alignment will affect its performance, but the program won't crash. It will still run and get the correct result. The third one is about stack growth. Most CPU stack growth is from higher address to lower. I only remember that Spark can adjust this option. For example, to change the stack growth, but I'm not sure whether anyone can turn on this option. It means one function calls another. It will save, for example, the most familiar x86. It will save the return address. Then the old stack frame. Old stack frame means the stack frame, which is the upper function. Then it's local variable. So the whole call stack is like this. So I think because my time is due. So I won't have enough time to show some code. Yes. Last question. Last question. Okay. Yeah, first question. Okay, okay. I think we will show the most complicated, stack growth code. We can see it's just a simple function call from the main to function two and call function one. Then we will use the GDB to show the whole call stack. So it's function two. Let me step into it. It's function one. Let me show the assembly code. Okay, so we can see now we will call the function one. Then we step into the function one. It's just a simple, just the same value to double type. Now let's check the call stack. Let's check the memory address. So it means now we will force the factor A address. Because the double occupies 8 bytes, so the first 8 byte is just A. Then according to this picture, old RBP, this one will be the stack frame of previous, that means the function two's stack frame. Then the third data, we can see 57. It's here. It's the return address from function one. So then this one, this is the function two's old static frame. It means the main function's stack frame. So maybe it's not clear here, so I think we can discuss about it. Any other question? Yeah. So I haven't heard about the difference between the beginning and the end since my architecture class and my second year of university. It's been a long time. I haven't had to use any of the knowledge. Why do I care about it? Yes, because the first thing is, for example, when you send the data from X86 to the network, the network data is actually used to big and for example, if you send the data from X86 and the other machine is bug, you must set up this protocol first. So it's all in the big and. I don't say any data. I don't have to go into that stuff. You know, I write like DHB. The library in PHP has encapsulated this for you. Yes. Okay. If you use a very sharp or TCP down to capture data to debug, you should know this thing. Is it useful when profiling or filing issues in your code? Profiling. Network profiling or? I think the big and end or late and end doesn't affect the performance very well. I think data alignment actually impacts your program's performance. Sorry. What's the reason we have these two different things? I haven't researched much, but I think in the beginning, different computer manufacturers will have different standards. But they will finally get one standard, a network-backed audio to convey each other, communicate each other. Just a context, right? What is the most different between by the line code and by the line code? From my experience, such as bug, I remember the ARM CPU, which you yourself use, it requires for the risk, it requires the straight-back alignment. If it's not by the alignment, the program will crash. I think for x86, if it's by the alignment, it will fetch data one time. But if it's not, it will fetch twice. Or fetch twice, then do some tricky things to guide the final data. Yeah. Okay. So, in terms of performance, is it not just one fold? It's not just two times the speed rate? No. I think it's at least two times, but I don't have a measured data from my experience. Okay. Thank you.