Re: Vector register 23?
Dan Greiner wrote: >Back in late September, I posted a link to a series of PowerPoint slides >that illustrate the operation of the z/Architecture vector-facility instructions. Thanks Dan! I could not find your note for some reason, and wasn't sure how public these were. Other folks: this is a great set of slides with a ton of useful info. What I said the other day was, in fact, extracted directly from Dan's work. .phsiii
Re: Vector register 23?
Back in late September, I posted a link to a series of PowerPoint slides that illustrate the operation of the z/Architecture vector-facility instructions. For those who missed it, you can find it on my Google Drive: https://drive.google.com/file/d/13OhBkhgbU7N6a20nVo5uEAnR-s3-Pyz8/view?usp=sharing The Overview.ppt file clearly illustrates that bits 0-63 of vector registers 0-15 are one and the same as bits 0-63 of the corresponding floating-point registers. Since this has been baked into the hardware architecture since the z13's debut in 2015, I think that the chances of IBM changing it are slim (somewhere between zero and negative infinity). Considering that the vector floating-point instructions (Chapter 24) provide equivalent function to that of BFP instructions (Chapter 19), with additional operations, wider registers, and twice as many registers as BFP, it seems to be of little concern that the floating-point and vector registers overlap. I expect that an application that starts exploiting VR floating-point ops will find little use for the FP instructions.
Re: Vector register 23?
On 12/8/2021 1:57 PM, Phil Smith III wrote: Peter, I expect I'm not the only one who's amazed by this. Not that I know enough to have a valid opinion, just that in this modren age of cheap memory etc., it seems surprising that these would overlap. Do you know why this was done? Is it something that could be "fixed" in a later machine, or is it now baked into the ecosystem and thus basically how it's gonna be forever? IBM Z processor chip real-estate can hardly be referred to as "cheap memory." -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Vector register 23?
Peter R. may answer on his own, but my impression is that this VR/FPR overlap
is part of the hardware chip design of the FPU part of the z chips, and the
fact that the zarch SIMD VR instruction functionality was (probably) initially
aimed at mathematical computations that need FPU operations. Not sure that
could change in a future HW/chip design, but you never know.
Then again, they could adopt the mighty-mite box solution of using (a) separate
GPU('s) with MIMD operations embedded for this stuff. Look at what the
crypto-currency miners are doing with loads of GPU's slaved together.
Peter F.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Phil Smith III
Sent: Wednesday, December 8, 2021 4:57 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Vector register 23?
Peter Relson wrote, in part:
>the part about regs 8-15 bytes 0-7 is related to the fact that the VR
>storage overlaps the FPR storage.
Peter, I expect I'm not the only one who's amazed by this. Not that I know
enough to have a valid opinion, just that in this modren age of cheap memory
etc., it seems surprising that these would overlap. Do you know why this was
done? Is it something that could be "fixed" in a later machine, or is it now
baked into the ecosystem and thus basically how it's gonna be forever?
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Re: Vector register 23?
Peter Relson wrote, in part: >the part about regs 8-15 bytes 0-7 is related to the fact that the VR >storage overlaps the FPR storage. Peter, I expect I'm not the only one who's amazed by this. Not that I know enough to have a valid opinion, just that in this modren age of cheap memory etc., it seems surprising that these would overlap. Do you know why this was done? Is it something that could be "fixed" in a later machine, or is it now baked into the ecosystem and thus basically how it's gonna be forever? ...phsiii (who acknowledges that his questions sound very normative)
Re: Vector register 23?
Robert Ngan wrote: Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. 16-23 only! Not 16-31. Is this correct? Yes it is correct (and you didn't even ask about VRs 0-7). As with the FPRs, some of the vector regs are considered "volatile" and need not be preserved if used. A program might be able to take advantage of that, if using the regs when not calling anything. Only the part about regs 8-15 bytes 0-7 is related to the fact that the VR storage overlaps the FPR storage. Peter Relson z/OS Core Technology Design
Re: Vector register 23?
Robert Ngan wrote: >Under "Saving the caller program's registers", the assembler services guide states: >Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. >16-23 only! Not 16-31. Is this correct? Well, "The vector facility for z/Architecture provides a set of 32 vector registers, each having 128 bits" so I dunno what it's describing. Maybe it's saying "Of the 32 VRs, some parts are unchanged, but other parts might be". Ah yes: A portion of the vector-register file overlaps the existing floating-point registers. Bits 0-63 of vector registers 0-15 co-exist with FPRs 0-15; bits 64-127 of VRs 0-15 and all of VFs 16-31 have their own unique locations in the register file. Those quotes are from some PPTXs that someone (I forget who!) sent me. ...phsiii
