Therefore, when we refer to the "top of the stack" remember it's at the bottom of the stack's memory.
I am reading a tutorial on x86 ASM and it has this. I really can't even begin to comprehend how this makes any dang sense. I assume it has to do with some hardware-level things, and as of now I know absolutely nothing about hardware.
Could someone maybe explain it? A diagram would be extremely helpful, but maybe just explaining why "the top of the stack" means "the bottom of the stack"
I definitely would not choose x86 as your first assembly language...But all of them pretty much have a stack.
Think of a stack of note cards each one of them can only have one note written on it. Say a grocery list, one says eggs, another milk another bread. So you can go look at the top one, right I need bread, get the bread discard the card. Next milk, right, go get that, discard the card, and so on. Oh, I need butter, write that on a new card, put that on the top, then go get that, take it off, discard it. And so on.
Now does it matter if say you had 20 cards, if the top card is numbered 0 the one below that is 1, and the one below that 2. or if the top card is 19 the one below that is 18, and then 17? Nope, so long as everyone who cares about what the rule is about numbering follows the rule then it doesnt really matter.
Why would we care about numbering the cards? Because that number is the memory address that is used for that item. If you number from 0 to N your stack is growing up in memory the oldest thing at 0 and the newest thing at N. or your stack may grown down from the top where the oldest thing is the highest address in the stack and the newest thing is at N. It is arbitrary so long as everyone knows the rules.
Another reason why we care is that some processors/many, have a way to skip, I want to peek at the third card down but when peeking I cannot remove it I can only remove or add from the top of the stack. What you can do though is also replace that third card down. Why would we care to do something like that? Think about local variables in a C function, maybe I have two local variables that are ints in my function. C is recursive so every time I call the function there needs to be storage for two more ints. The stack is perfect for that. As soon as I am in the function I add two blank cards to the stack, while running that function if I need to access those ints, either read them or write them I can peek at or replace those cards with a card with some new value. When I exit the function I remove both cards and discard them leaving the stack the way I found it when I got there. The stack was temporary storage during the function, but in a way that I dont care what the address is I only cared that the two cards on top were mine, and I could get at both of them the stack could have been 1000 cards tall or 8745 cards tall doesnt matter I only cared about the top two, all the cards below me belong to functions that called functions that called me. Each function that exits cleans up the cards that belong to it.
the stack is just memory and pointed at with a pointer register called the stack pointer. this makes it such that we dont care what the specific addresses are we only care about what they are relative to the stack pointer. We do have to know and follow the rules for that processor or convention for that processor or environment to know which way to do the offsets, if the stack grows downward meaning sp = sp - 3(locations) adds three blank cards to the stack, and sp+0 is the top sp+1 is the next one down on the stack and so on. If the stack grows up in address space (not all that common but there are some that can or do) then sp = sp + 3(locations) is how you add 3 new things to the stack, and sp-1 is the first one down, and so on.
It is not the dark ages of computing, I recommend learning C a bit better or some programming language get the programming thing down in any language, able to break a problem down into steps and implement the steps in order to complete a task. Then asm is simply breaking those steps down into smaller steps and implementing those in order. Again I recommend almost anything but x86 as a first instruction set, and I recommend using an instruction set simulator (simulator or emulator) and not real hardware for your first assembly language, once you start to get the hang of it and in particular debugging your asm you will understand completely, esp if you start with a more straightforward instruction set and then later look at x86. msp430, arm, pdp11 (yep, I am very serious), avr and a few others are good first instruction sets. but get to some level of experience with C or something like it before diving into asm.
