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=shari
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 t
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. N
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., i
Coupling Facility XCFNOTE services is a callable service can be used to
create/read/modify data across applications or the entire Sysplex. Access to
the data notes can be controlled and locked down by your SAF. The services can
be called in problem state without the need to create special author
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
