|
|
|
| Authored by: eric76 on Tuesday, May 22 2012 @ 03:58 AM EDT |
Not too bad an explanation of the program stack.
In many language implementations, variables declared statically are also stored
on the stack. The nice thing about this is that when exiting the routine you
don't have to do anything to deallocate the storage -- just unwinding the stack
handles that nicely.
On the PDP-11, there was an instruction you could push on the stack that you
would branch to at the end of the routine to automatically clean up the stack.
At a Birds of a Feather meeting on assembly language at a DECUS in New Orleans
in the mid 1980s, someone asked if anyone use it. As far as I could tell, I was
the only one in the room who used it. So it wasn't used much (which may explain
why the description of it in one popular programming book/manual was somewhat
incorrect). It was also useless if you used I and D space (instruction space
and data space) since the stack would be in D space, not I space. Attempting to
execute the instruction at a location in D space would instead execute the
instruction at the same numeric location in I space.
That said, I don't see how the java stack could be implemented on the program
stack. Perhaps there is some really unwieldy way to do it, but it would be
overly complex and more likely to break. For any non-compiled java, there
would need to be a java interpreter and it would undoubtedly use the program
stack, not the java program being interpreted/executed.
The only way the java stack makes sense to me is if it is a separate allocation
of memory that is then accessed with the normal push and pop stack operations.[ Reply to This | Parent | # ]
|
|
|
|
|
