4 ms·
I didn't get the part about the stack in assembly, in my experience the stack is very much a thing at that level. Mainstream CPUs expose one or more explicit s
by unwind 2y ago
I didn't get the part about the stack in assembly, in my experience the stack is very much a thing at that level.
Mainstream CPUs expose one or more explicit stack pointers, and in assembly you use that all the time, right?
- elteto 2y agoI think he means that the stack is not something that you are forced to work with when programming in assembly. You can put data wherever you want (and are allowed to), and jmp into whatever random memory address you want. You can use CPU instructions that handle stack management for you, but you don’t _have_ to.
- immibis 2y agoSomewhere on my random ideas pile is to write a queue-oriented operating system - you know how we have threads? What if we didn't have threads, just a list of things to do, to run on the next available processor? (Haskell's VM calls them sparks)
- kaba0 2y agoI mean, that's just a register. The memory region itself is not special in any way, a random "heap" region that would be similarly frequently accessed would be just as fast.
- gus_massa 2y agoYou also can peek and write in the wrong side of BP and mess the "stack" of the caller funcion and perhaps get unexpected results or nasty crashes. Instead of "an ilusion", I'd say it's "a convension".
- unwind 2y agoExcept of course how return addresses are typically always stored on the machine stack. It is very concretely there and part of the programming model, in my world.
- gpderetta 2y agoTechnically some CPUs have a "jump and link" that saves the return address in a register. Then it is up to the calling convention to save that register on the, also by convention, stack.