reg@lti.com (Rick Genter x18) (10/25/88)
> Can someone explain to me what the difference is between a hardware stack > and a software stack? The difference is that a machine with a hardware stack can dereference the top of the stack and modify the stack pointer as an atomic operation (usually via an addressing mode). A machine with "only" software stacks must use multiple machine instructions to perform this operation; this makes things hairy in the world of interrupt processing. Not impossible; just hairy. An example is the IBM/370 architecture: there one uses static saveareas for handling interruptions/exceptions. Yuck. - reg -- Rick Genter ...!{buita,bbn}!lti!reg Language Technology, Inc. reg%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (508) 741-1507
sbigham@dukeac.UUCP (Scott Bigham) (11/03/88)
In article <8810242200.AA05011@lti.com> reg@lti.com (Rick Genter x18) writes: >The difference [between hardware and software stacks] >is that a machine with a hardware stack can dereference >the top of the stack and modify the stack pointer as an atomic operation >(usually via an addressing mode). A machine with "only" software stacks >must use multiple machine instructions to perform this operation... What of the 68000? By your argument, it has a hardware stack, since I can push something onto the stack with MOVE.L #FFFF,-(SP). But suppose I allocate a chunk of memory and set another address register (say A3) to the top of it. Then I can say MOVE.L #FFFF,-(A3) et al; essentially, I've just produced my own stack out of thin air. I would call this a software stack, since it wasn't there when I turned the machine on. But then why isn't the SP-based stack a software stack? (Remember, SP is just A7) Just to add my <= $0.02, I would say that a machine has a hardware stack if you have to go through a bunch of ugly machinations to implement your own stack; otherwise, it has a software stack. Someone more net-knowledgeable than myself may wish to redirect followups elsewhere. I would if I knew where to. sbigham -- Scott Bigham "The opinions expressed above represent Internet sbigham@dukeac.ac.duke.edu me and everyone that agrees with me. USENET sbigham@dukeac.UUCP If that includes Duke University, ...!mcnc!ecsgate!dukeac!sbigham I'll be amazed."
mikes@oakhill.UUCP (Mike Schultz) (11/10/88)
In article <1075@dukeac.UUCP> sbigham@dukeac.UUCP (Scott Bigham) writes: >In article <8810242200.AA05011@lti.com> reg@lti.com (Rick Genter x18) writes: >>The difference [between hardware and software stacks] >>is that a machine with a hardware stack can dereference >>the top of the stack and modify the stack pointer as an atomic operation >>(usually via an addressing mode). A machine with "only" software stacks >>must use multiple machine instructions to perform this operation... > >What of the 68000? By your argument, it has a hardware stack, since I can >push something onto the stack with MOVE.L #FFFF,-(SP). But suppose I >allocate a chunk of memory and set another address register (say A3) to the >top of it. Then I can say MOVE.L #FFFF,-(A3) et al; essentially, I've just >produced my own stack out of thin air. I would call this a software stack, >since it wasn't there when I turned the machine on. But then why isn't the >SP-based stack a software stack? (Remember, SP is just A7) That is correct, but remember that there are instructions that know about A7 being the Stack Pointer. Instructions like JSR, BSR, RTS, RTE. Also the processor uses A7 to push state information on the stack during exceptions. Plus there are really two A7's, one which is active when the supervisor bit is set, and another when it isn't. So, it is true that you can implement a software stack on the 68000, but enough of the hardware knows about A7 being used as a stack pointer to qualify it as a hardware stack. Mike Schultz Motorola Inc, Austin Texas ....!uunet!cs.utexas.edu!oakhill!mikes