32-bit z/Arch

[[e-mail]]

Not quite there yet - current status is here:

https://gcc.gnu.org/pipermail/gcc/2021-September/237215.html

[Joe Monk]

Post by ***@gmail.com
https://gcc.gnu.org/pipermail/gcc/2021-September/237215.html

"I think z/OS is pretty much still 31-bit only,
as far as apps are concerned, right? I’d like to
bump that up to 32-bit."

No, thats not correct. CICS, DB/2, IMS DB/DC, and most LE compilers (PL/I, COBOL, FORTRAN, C) are all 64-bit.

Joe

[Joe Monk]

"I wish to demonstrate the minor changes
that would have been required to the S/360 so that
we would never have arrived at a 31-bit black hole,
and we could have in fact had the perfect 32-bit
machine."

They were not "minor" changes. For example, the S/360 used core memory. How much more memory (and hardware changes) would have been required to implement 32-bit memory as opposed to the 24-bit memory?

Joe

[Joe Monk]

Post by Joe Monk
They were not "minor" changes. For example, the S/360 used core memory. How much more memory (and hardware changes) would have been required to implement 32-bit memory as opposed to the 24-bit memory?

For instance, from the 360-91 functional characteristics, the processor storage capabilities, the system could only have 2MB of main storage, and 4MB of extended storage.

In 1960's memory was approximately $2.6 million per megabyte. So, a fully loaded 360-91 with 6 megabytes of storage was north of $12 million in 1960 dollars.

According to the inflation calculator, $1 in 1960 buys the same as $10 today. So, the same computer in todays dollars was $120 million! And IBM spent $5 billion in 1960 dollars to develop the 360...

Joe

[Joe Monk]

Finally, I would point out that the IBM 360 instruction set is incompatible with 32-bit addresses.

For instance, LA clears the top 8 bits... (p.56)

"The address specified by the X2, B2, and D2 fields is inserted in bits 8-31 of the general register specified by R1. Bits 0-7 are set to zero. The address is not inspected for availability, protection, or resolution."

BXH and BXLE use signed arithmetic... (p.66)

"All 32 bits of the general registers participate in the operations, and negative quantities are expressed in two's-complement notation."

http://www.bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf

Joe

[[e-mail]]

Post by Joe Monk
Finally, I would point out that the IBM 360 instruction set is incompatible with 32-bit addresses.
For instance, LA clears the top 8 bits... (p.56)
"The address specified by the X2, B2, and D2 fields is inserted in bits 8-31 of the general register specified by R1. Bits 0-7 are set to zero. The address is not inspected for availability, protection, or resolution."
BXH and BXLE use signed arithmetic... (p.66)
"All 32 bits of the general registers participate in the operations, and negative quantities are expressed in two's-complement notation."
http://www.bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
Joe

Jesus Antonio now has this working on standard z/Arch:

https://gcc.gnu.org/pipermail/gcc/2021-September/237457.html

BFN. Paul.