A very complex imaginary architecture was defined here, primarily motivated by what I perceived as a flaw in the architecture of the IBM System/360: that the displacement field in an instruction was only 12 bits long, instead of 16 bits long, as on many microprocessors or the PDP-11.
But could there be a way of addressing this issue while still having an architecture closely based on the System/360 architecture? This diagram illustrates three possible schemes for doing so:
The choice of registers to make available as base and index registers in the various instruction formats requires some explanation.
Certain conventions used in System/360 coding, particularly the S-type subroutine calling convention, explain much of those choices.
In the S-type subroutine calling convention:
This is why, in all three modes illustrated above, a special effort was made to allow the use of General Register 13 as a base register for RS format instructions, as the LM (Load Multiple) and STM (Store Multiple) instructions are in that format.
As well, General Register 1 is used as a pointer register for various purposes; in subroutine calls, it contains the pointer to the argument list. In Mode 1, this is handled by using GR1 as the base register in what would otherwise be a duplicate addressing mode for the RX instruction format (similarly, GR6 and GR7 are also allowed as additional base registers for RX-format instructions in this fashion); in Mode 2 and Mode 3, again only in the RX format, instead of allowing GR8 as a base register, zeroes in the three-bit base register field indicate absolute addressing, allowing a pointer register to be indicated in the index register field.
Mode 2 derives its inspiration from the IBM System/360 Model 20 computer, allowing a 15 bit displacement only when general register 12 is used as the base register.
This allows the use of eight base registers in the RX format; but in other formats which do not normally allow indexing, only five base registers may be used, so that the extra space made available by reverting to 12-bit displacements can also be used to allow instructions in those formats to be indexed.
Mode 3 attempts to make more options available by accepting a 16 kilobyte segment size; this is smaller than 32 kilobytes, but still significantly larger than 4 kilobytes.
IBM extended the original System/360 architecture all the way to z/Architecture while maintaining almost complete upwards compatibility. My goal, instead, is to provide an architecture that is as efficient as if it were designed from scratch, which, while it is not compatible with that of the System/360, allows for easy porting of software on the one hand, and which has a sufficiently high degree of commonality with the IBM mainframe architecture so as to permit an implementation to switch between the new architecture and 370-compatible operation with a limited amount of additional hardware.
Therefore, the instruction set would use many of the instructions of the original IBM 360 and its successors, but with the opcodes for hexadecimal floating point instructions used instead for IEEE 754 floating-point, and with applicable string instructions such as the ED (Edit) instruction working with ASCII (not ASCII-8) rather than EBCDIC characters.
This avoids the need to use longer format instructions for binary floating point, and as well longer displacements are obtained without going from the 32-bit RX format to the 48-bit RXY format (or RSE), or from RS to RSY (or RSE) or from SI to SIY.
But attempting a retrofit to the System/360 architecture poses a significant difficulty compared to starting with a new architecture. In my new architecture, I had the freedom to take one bit away from the destination register field, and one or two bits away from the opcode field of an instruction. In addition, to allow indexing with instructions that had both operands in memory, I could simply lengthen them to 64 bits. Without these options being available, more serious compromises must be made.