jimp@cognos.uucp (Jim Patterson) (11/08/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). > >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). ... > >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. This seems exactly opposite to what I would expect. A hardware stack by Mr. Bigham's definition doesn't require "ugly machinations" to implement your own stack; you use the same facilities used by the system architecture. I wouldn't call the 68000 stack a "software stack" for simply that reason, though. I would define a hardware stack a little more strictly. As I see it, the term "hardware stack" indicates a stack that certain machine instructions or operations implicitly depend on (i.e. the stack pointer is an implicit argument, as opposed to the "-(SP)" argument in your example which is an explicit argument). The most common such instruction is the CALL or JSR instruction in many architectures which pushes the return address onto a stack. Interrupts are not instructions per se, but are operations that also often require a stack to be present in order that they can save state information. Usually such stacks are set up by software, so you will find that the reset or startup logic for such systems is expected to set up a stack before allowing stack-referencing instructions to execute. Also, destroying the stack pointer or violating stack protocol (e.g. by writing below the stack pointer if it grows downwards) can be expected to lead to misbehaving code or crash the system if it has a hardware stack. Any machine with reasonable pre-increment/post-decrement instructions is able to implement a software stack efficiently. This really has little bearing on whether it does or doesn't have a "hardware stack" by my definition (but not by Mr. Bigham's obviously).. However, I think that more often than not these features tend to occur together because the hardware to implement one is available to implement the other. Every micro architecture that I can think of fits this definition of having a hardware stack. (There are likely some simple control processors that don't, but you wouldn't likely find them as the main processor of a microcomputer). A well known example of a computer (not a micro) which doesn't have such a hardware stack is the IBM 360/370. Its call instruction is BALR or BAL, which store the return address in a register. I believe that its interrupt protocol generally stores registers into static areas instead of a stack. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4