Відео

I hope this will clarify your issue: (1) Each stack entry consists of 128 bits, which we can think of as 2 chunks of 64 bits. If the Stack Pointer currently points to address A (top of the stack), then writing something onto the stack will fill up the bytes at addresses A, A+1, A+2, ... , A+15. Just to be clear: In the image in the video I assume that the lower addresses _within_ a stack entry start on the left. (2) The growing of the stack (towards lower addresses) refers to the initial addresses of the stack entries, which by (1) are 128 bits apart. For example, if the current top of the stack is at address A, then pushing something onto the stack will make the Stack Pointer point to address A-16, which is reflected in the parameter #-16! in the STR instruction. (Check: This new stack top includes addresses (A-16), (A-16)+1, ... , (A-16)+15, so that it stops precisely at the address A, which is the beginning address of our previous stack top.) (3) The register X0 is 64 bits (8 bytes) in size, so it will occupy half of a stack entry. The STR instruction as stated in the video will store X0 at the current address A of the Stack Pointer, which points to the lowest address of the current stack top. So the 8 bytes that make up X0 will be written to the bytes at A, A+1, A+2, ... , A+7 on the stack. These are what I call the "lower order bytes" of the stack. Strictly speaking, this does not depend on a little-endian or big-endian convention, since the operations involved do not in any way depend on that. It would be the responsibility of the programmer to make sure the data is stored in the register in the correct manner and the pushed to the stack in the correct order.

@@hackvlix Thank you so much for the very detailed explanation. Now I think I've got it! Thanks!

Glad you like it :)

I could put less content on my slides, then what I say would not appear like reading them. Would that be fine? But seriously - upon closer listening you might notice that often I am not just literally reading the slides but also give additional commentary (granted, this might be more noticable in other videos). I believe that it can help many people retain their attention if they are not just reading something, but can aditionally listen to someone explaining it. Sure, this might not be the preferred mode of studying for everyone, e.g. some people might prefer to just read a book by themselves. But there's always the option to simply not watch my videos and get yourself that book. I'm speaking too slowly? Thankfully, UA-cam offers the feature to watch the video on 1.5x or 2x speed. Not interested in a particular part I am explaining? UA-cam allows you to skip over it until something more interesting comes up. The timestamps in box might be helpful here. Don't care for the explanations and just want to see the coding bits? Again, just skip forward, even though I think it is helpful to get something explained in principle first and then see how it is done in practice. Given all these possibilities to customise your learning experience on UA-cam, I prefer to err on the side of completeness by providing rather too much, of which the audience my decide to leave it out, rather than providing too little.

Glad that you like it... and, yes, RISC definitely does not mean reduced complexity for the programmer.

Ni

Thanks, glad you like it. 🙂 I hope I get a video on file operations out soon - stay tuned!

Thanks, glad you like it!

M1: ARMv8.5-A M2, M3: ARMv8.6-A You can find these in the LLVM source code (search for "apple" or whatever chip you are looking for): github.com/llvm/llvm-project/blob/main/llvm/include/llvm/TargetParser/AArch64TargetParser.h

@@hackvlix Thanks. Do you know what are the general purpose registers that can be safely used by the user in ARMv8.5/6-A. I read somewhere that they were X0-X30, but then I read somewhere else that X18 should not be touched, and that X8 serves a specific purpose. which one is true?

@@younesmdarhrialaoui643 Some remarks at 6:18 in the video. A nice overview is given in this graphic: documentation-service.arm.com/static/5fbd26f271eff94ef49c7018

@@hackvlix Thank you very much, you're amazing. Here is something I don't understand though: They call the X0-X30 general purpose registers meaning they can be used for anything the user wants them to be used for. But the weird thing is that some of these registers shouldn't be touched like X18, or X29 (the frame pointer). If I store a value in X29 and do some math it will have different consequences then if I did it on an "actual" gp register. Can you explain to me this confusion?

@@younesmdarhrialaoui643 No, using X29 for some operations will not have different consequences than using any "normal" register. But the problem is that by overwriting X29 you might mess up the stack frame and cause a crash when a program tries to unwind the stack with the overwritten frame pointer, that's why it's better to not use it. As for X18, I do not know what Apple has reserved this for, but it is suggested not to use it.

Glad you like it. 😊

Except for COBOL perhaps... just kidding, it's true, in Assembly, "Hello World" requires you to do some actual work, whereas for higher languages, it usually serves to give a first feel of the new language.

Yes, thankfully it will. With COBOL, it's a bit trial and error finding out where the compiler accepts/demands/rejects a period. Perhaps it also depends on the particular compiler.

Though there is a difference between the COBOL period and the semicolon in other languages (because, hey, let's not make it too easy!). The COBOL period is not just a statement terminator, so in some contexts, say IF-THEN-ELSE statements, which COBOL deems "sentences", there may be only one period to for the whole sentence. It's not always helpful for readability if there are a few instructions with several parameters that are not separated by periods.

লিক হাো

Thanks, I'm happy it helps.

Haha, thanks - glad you find it helpful 🤗

Haha, nope. The octopus is from Ernst Haeckel's book "Kunstformen der Natur" (1904). It is not copyrighted.

r/confidentlywrong

Thanks, I'm glad you find it helpful. As for the voice... "geez, do I really sound like this?" 😉

Sorry, I don't really know what the issue is. What path do you get when you run xcrun -sdk macosx --show-sdk-path ?

Thanks! Glad you like it.

Glad you like it. I've had some familiarity with Intel assembly for quite some time, so it's hard to say exactly where I learned it. There are a few differences between Intel and ARM, but they a rather easy to understand if you already know one of the two. As for ARM assembly, I mostly learned it from the book in my first reference, and the link in the second reference contains the details to apply it to macOS. The technical minutiae such as the bitwise encoding of the ARM instructions can be found in the Arm Architecture Reference Manual (third reference above).

You're welcome. Glad you like it.

Great to hear! 😀 Good luck with your studies!

Noted. :) As I said, I have no particular idea what to do there right now.

@@hackvlix tcc bypass, dylib injection 🙂 might be good

@@hackvlix Also PAC in m1 I don't have m1 so I have no idea how PAC works. if possible

Muchas gracias. Qué bueno que te guste.

Hm, this is a bit puzzling for me. This error occurs when the assembler cannot resolve the address of a label. Just to check - you have used the "as" and "ld" commands as described in the video? Could it be that you put the label "helloworld" in the ".data" section? In that case, the ADR instruction as used here would not find it.

@@hackvlix, this seems to have fixed the error for some reason haha adrp x1, helloworld@PAGE add x1, x1, helloworld@PAGEOFF

@@hackvlix And yeah, seems I put .text and .data labels in my code, whoops

​@@brook1598 For longer code, it is probably better to use the .data segment. The ADRP instruction makes it possible to defer address resolution to the linker if the assembler cannot resolve the address. This is actually an interesting addition to the video.

@@hackvlix Ahhh okay interesting, this is my first time learning any assembly and it's been super interesting. Apart from using these awesome videos you've produced here would you say that "Programming with 64-bit ARM Assembly Language" with the additional "Hello Silicon" repo is enough to get me started? Would you recommend any other resources in addition to the ones in the description? I just want to thank you for making these videos, these are super helpful and in a format that is interesting and visually appealing, especially with the examples you give. Keep up the great work!

Thanks for watching, glad you liked it.

Glad you like it!

Thanks! I will try out Audacity.

Oh, first comment on the channel ever. 😀 Thanks a lot, I'm glad you liked it.