IBM Mainframe Forum

I am nearly certain that no, IBM mainframe processors do not have stacks implemented by the processor.

It has been about thirty years since I did any 370 style mainframe assembler. I know about the 370 style of convention of pointing to a save area using register 13 (right?) and such. So I know we did not use a stack for calling functions and passing parameters and saving registers and all that.

Fast forward to now. I see many questions about stacks and most developers are familiar with x86 architecture. If I say that So as best as I know, the IBM Z processors can be called the fastest processors that currently exist and available for purchase (for a about a million). I tried to search for answers but it is not easy to get a clear answer to this question. Do Z processors, the fastest processors that exist, implement stacks using the processor in a manner equivalent to Intel X86 processors and available for use in languages such as C++? I assume that C++ and such languages have their own implementations of stacks separate from the processor.

I mainly want assurance that I can say that IBM processors that are the most powerful or among the most powerful do not have stacks implemented by the processor.

I tried downloading the Z processor Principles Of Operations but IBM declined to allow that. I first read the 360 POPs in about 1970. I wanted to see if the instruction set is fundamentally the same for Z processors. Is it?

I tried downloading the Z processor Principles Of Operations but IBM declined to allow that.

You have to register to do it

Yes, mainframes have a stack, but it is not accessed or used in the same way X86 machines access and use the stack.

There are two ways to add data to the stack: the PC instruction and the BAKR instruction. PC is used in some IBM macros to call a service in a manner similar in concept to call gates in X86; the BAKR instruction can be used in programs. BAKR can be used as the equivalent of a CALL, or it can be used at the start of a program to stack the environment. There is no equivalent to the PUSH and POP instructions in stack oriented architectures.

The PR instruction is used to restore registers from the stack and remove a stack entry and return.

I do not recommend using these instructions. They are v-e-r-y slow. There is the cost to create and remove a stack entry, plus PC and BAKR store the PSW, 16 general registers, and 16 access registers. Obviously PR puts humpty back together. This cost highlights the primary disadvantage of a register rich hardware environment, which X86 is not. Status changes, whether they are from a PC or BAKR, from a regular CALL type facility, or from a hardware interrupt are very slow. On the other hand, programs should be faster since registers are much faster than pseudo registers in storage manipulated by PUSH and POP instructions. Since it appears just about every hardware architect than the IBM mainframe seems to be stack oriented it seems most people feel the stack model is superior. My qualifications as a hardware architect are too limited to comment on this in a way that would satisfy academics.

However, I just want to make one additional comment.

In the 1990s, at roughly the same time as the mainframe stack was rearing its ugly head. IBM devised the XPLINK concept to improve the performance of C++ type applications. This performance improvement does not use BAKR/PR. Primarily it tries to streamline the traditional CALL/RETURN mechanism by saving and restoring as few registers as possible, something foreign to BAKR/PR. There are detail changes to optimize hardware in an environment where the hardware is using pipelines to improve performance, but the biggie, to my mind, is the register optimization in CALL/RETURN.

You also asked, in essence, if the the System/360 instructions are still there. Yes, they form the core of z/Architecture for problem state programs. Yes, there are additional instructions, and, yes, many of them are used by most programmers, but at least 90% and it's probably higher, of the executed instructions are System/360 instructions. Yes, there are detail changes, but a System/360 expert suddenly transported to 2018, could recognize and understand a 2018 z/Architecture z/OS program. Similarly, most System/360 OS/360 problem programs transported to 2018, will assemble and run today.