Probably ruled out by the "no forth" rule, the 6809 had data register stacking instruction for either the S or the extra U stack pointer PSHS | PULS | PSHU | PULU X,Y,D,CC,... and I think you could use PULU PC,... for return, just like you commonly use PULS PC,... as a quicker way of the standard return sequence PULS ... RET Saving time stacking the data registers might make up the extra time for nonstandard call resolution sequences. -- strick

While a hardware stack may be useful, I don't consider it to be essential and perhaps counter-productive. (dodging brickbats). I say that because if a recursive solution to a problem is available on a stack-oriented architecture, the natural impulse is to program a recursive solution. Lack of hardware support for recursion might otherwise push one toward an iterative approach, which in many cases can perform better. --Chuck

The PDP-8 didn't have a stack pointer at all.  Many interpreters and compilers implemented their own software stack. Architectures like the 6809 and PDP-11 and 68000 lend themselves to creating multiple software stacks. On 2/17/2025 11:56 AM, ben via cctalk wrote:

On 2/17/25 08:02, Frank Leonhardt via cctalk wrote: Yes, on the PDP11, any register could be used as an autoincrement/decrement indirect pointer.  So, the use of R6 was merely a convention, baked into the macros in the assembler.  R7 was firmly fixed in the CPU logic as the PC, however. Jon

Don't know if it was mentioned, but the NS16032 (later renamed to NS32016) employed two stack pointers (SP0 and SP1), but the implmentation was one for user stack and the other for interrupts. Which only made sense--you don't want your privileged-mode ISRs corrupting the user stack or vice-versa. --Chuck

So do PDP-11 and VAX, but that isn't really what the original question was about. For those, there is only one stack at a time, but a different internal register in the CPU is referenced when the "stack pointer" is needed, depending on the current mode. An interesting variation of that is the Philips PR8000, which has 8 general registers (well, one of the 8 is the PC, like on the PDP11) though no stack. But actually it has 8 sets of 8 registers, one for each processor priority level. So an interrupt automatically preserves the previous registers, and the interrupt handler address is simply the value found in R0 (the PC) for that level. paul

On Wed, 19 Feb 2025, Paul Koning wrote: That is not unusual at all. The IBM PALM processor does this for example, only that is has four sets of 16 registers. An interrupt just "shifts" the register base address to $20 * interrupt level. There is no instruction overhead at all. A "return from interrupt" merely clears the interrupt request line for that level and the processor pops to the next-lower active level, level 0 being the default. Same with the MINCAL 523. The basic machine has eight run levels, expandable to 64 levels. The default and lowest level is 0. You can change the level either by an interrupt to that level (if not masked and no other higher priority level is active) or by a processor instruction (making kinds of subroutine calls effectively overhead-less; no need to save the return address). The registers (also in memory space) are offset by 8, so level 0 has its registers at addresses 0..7, level 1 at 8..15 and so on. But, back to the topic, none of these machines have a hardware stack, although on the MINCAL, you can write additional microcode and create new instructions for what you like. Christian

That reminds me that the PDP-11 has the ability to send interrupts to modes other than kernel mode, because the new processor status (which includes the mode) is part of the interrupt vector. I doubt that has ever been done, though. One complication is that an interrupt into user mode that interrupts kernel mode code would be a dead end, because the RTI instruction can't restore the state then: in user mode it can't restore a PSW value that says kernel mode. So a user mode vector would work only if the kernel is not interruptible at all. paul

What is the problem with ISRs running in a user stack? The ISR runs, exits, the stack is cut back, and net effect on the user's stack is zero. The Burroughs B6000/7000 (later Unisys A Series and now ClearPath MCP) systems did that, and it works fine. An interrupt acts like a hardware-induced procedure call. The user's state is pushed onto the stack, a new stack frame is started, and the interrupt routine runs in that, calling other OS procedures as necessary to do its job. If execution of the user task needs to be suspended, say to wait for an I/O, the OS moves the processor to another stack (there's a privileged instruction to do this). Once control returns to the original stack, the OS procedures eventually exit back into the interrupt routine, which exits back into the user's stack frame, with the hardware restoring the prior stack frame's state at each step. There are perhaps two significant differences with this architecture, though, that help to make this work. First, there are no user-accessible registers. All registers are dedicated to specific purposes, which is what allows the hardware to save and restore state automatically. Second, the stack on these machines is not part of the user's address space, it IS the user's address space. All push-down expression evaluation and call history is in the stack and is managed automatically by the hardware. All addressing is relative to the stack. Scalars are typically allocated in the stack. Arrays and other larger structures are allocated in separate segments elsewhere in memory and accessed through descriptor words in the stack. Procedure parameters are contained in the callee's stack frame and effectively become local variables for that environment. The instructions do not have memory addresses, not even virtual addresses. All addressing is in terms of offsets from the base of a stack frame or from the base memory address in a descriptor word. So the stack is not an afterthought made feasible by auto-incrementing a register. It's a central tenet of the architecture.

Ah. In the Burroughs/Unisys architecture I was describing, there's no such thing as a running application not having a valid stack. Well, gross hardware or OS errors might result in that, but not user actions. A stack is the basis for all addressing that an application task does, so if there's no stack, there's no running application. Also, a user task cannot address above current top-of-stack or below bottom-of-stack -- there are bounds registers that enforce that. A user task also cannot mess with the stack linkage words that store state, the return location, and the link to the prior stack frame, since those words are managed by the hardware and protected as non-writable with memory tags.

As I mentioned in my last reply to Paul Koning, that can't occur in the Burroughs/Unisys stack architecture I was discussing earlier. Application code can only access what it has created by pushing words onto the stack, and then only access those stack frames that are in the lexicographical scope of the currently-executing procedure. It can't access memory outside of that current scope, except through references and descriptor words, which are protected by memory tags and managed only by the combination of the hardware and OS. Those systems do not have threads in the same way that most other systems do. We call them sub-tasks or dependent asynchronous tasks. They each have their own stack, which is linked back to the specific stack frame that initiated them (the so-called "critical block"). Addressing within the sub-task is subject to the same scope rules as the parent task, although that scope can extend across stacks into the parent's stack. If the parent task exits a critical block for which there are active sub-tasks, the parent and all of its children (and their children -- the whole tree of sub-tasks) is terminated by the OS because the dependency chains have been broken. Applications are just not allowed to mess with the structure of their stacks.