Hacker News Reader

Comment by unwind | Hacker News Reader

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?

I 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.

Somewhere 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)

I 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.

You 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".

Except 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.

Technically 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.

Reply on news.ycombinator.com