curious: MVHI vs XC to "zero" a halfword.

[John McKown]

Why am I asking this? Because I just installed a product on our, very old,
z9BC. Said product's documentation said it was supported on a Z9. But it
abended S0C1 on the instruction: E54C 1000 0000 (MVHI 0(1),0). I looked
this up and it appears to be part of the "general instructions extension
facility", which came in on the z10 class. Now, I know this code was likely
generated by the C compiler (given the, unnamed by me, vendor). But this
seems to be what I would expect to be from something like the C code: short
int somevar=0; So I guess that is the reason: a general template which uses
MVHI to set a halfword integer to a constant value.

But, in the case of hand crafted assembler, would an MVHI be "better" than
an "old style" XC for some reason? I am thinking speed, having the operand
in the i-cache, and so forth. Or is an XC of a region with itself
"optimized" in the hardware to not actually fetch the data and do an XC
operation because the result is always b'000...' regardless of the operand?

--
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

[Potts, Michael]

It's most likely optimized in the hardware, so it wouldn't matter if you used XC or MVHI in terms of performance.

However, if you're setting a fullword in storage intended for math operations to 0 (i.e. "int elephants = 0;" in C), MVHI makes more sense than XC in my mind since the MVHI instruction itself is more self-documenting than XC to describe what you're doing. If you were trying to mentally reverse engineer the XC instruction back to C code, it would look something like "int elephants; elephants = elephants ^ elephants;" That's confusing!

[Martin Truebner]

John,

i have no clue about the hardware-

one thing: the XC can only be used to clear it- the MVHI could be used
to create any memory-configuration possible into the half-word- so...

The stmt ".... product's documentation said it was supported on a
z9" is correct if it continues with

... "---when compiled with the right archlvl"

just saying

Martin Trübner; everything around "PoOps of z/arch"

[John McKown]

On Thu, Jan 12, 2017 at 8:58 AM, Martin Truebner <mar...@pi-sysprog.de>
wrote:

> John,
>
> i have no clue about the hardware-
>
> one thing: the XC can only be used to clear it- the MVHI could be used
> to create any memory-configuration possible into the half-word- so...
>
> The stmt ".... product's documentation said it was supported on a
> z9" is correct if it continues with
>
> ... "---when compiled with the right archlvl"
>
> just saying
>

​True. Just continuing in my "research", I noticed that the program in
question _was_ compiled on z/OS 2.2 (we are z/OS 1.12!) and _appears_ to be
written in C (just from looking at some of the stuff inside it such as
seeing "sprintf"). Interestingly, the z/OS 2.2 C compiler does support
ARCH(7) for the z9. But ARCH(8) is the default starting with z/OS 2.2. But
the TARGET, to set the LE level, only goes "down" to z/OS 1.13 (it was 1.12
in 2.1 because I remember when I used C on a 2.1 system which is now 2.2).​

>
> Martin Trübner; everything around "PoOps of z/arch"
>

[Gary Weinhold]

There`s a little more work for XC, even optimized, than for MVHI, I think, since it has two addresses to translate. Of course that could be optimized, too, and perhaps both are done within a cycle anyway. My experience, based on software development, is that at some point optimization slows down the normal path so much it`s no longer a net benefit.

Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone: +1.613.523.5500 x216<tel:+1.613.523.5500%20x216>
Email: wein...@dkl.com<mailto:wein...@dkl.com>

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/>

Visit us online at www.DKL.com<http://www.dkl.com/>

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig>

E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.



__________
On 2017-01-12 10:10, John McKown wrote:

On Thu, Jan 12, 2017 at 8:58 AM, Martin Truebner <mar...@pi-sysprog.de><mailto:mar...@pi-sysprog.de>

[Steve Smith]

Just to be clear, MVHI expands a source half-word to set a full-word.
MVHHI is for half-word targets, and what MVGHI does is left as an exercise
for the student. Regardless, sure seems like MVFHI would have made more
sense as the first's name.

Aside: if you don't already know, guess what the MY instruction does. Then
look it up.
And 1 more: Why is there no LFI instruction?

sas

--
sas

[Blaicher, Christopher Y.]

It's called LLILF. There is also LLIHF to load the high 32 bits of the register. Also see LGFI.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803    
E: cbla...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA

[Steve Smith]

LGFI and LLILF load 64 bits. As do LGF and LLGF. But what corresponds to
L, an immediate instruction to load only 32 bits?

AFI, CFI work on 32-bits (vs. AGFI, CGFI). Yet no LFI.

Well, the answer is IILF, as the architecture guys are loath to have two
instructions that do the same thing. Although HLASM could make LFI an
alias for IILF, and saved me the time I spent looking for it.


sas

--
sas

[Robin Vowels]

When all else fails, there is always SR 0,0 and STH 0,X
Or even 2 MVIs.

Maranatha! <><
John McKown

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Blaicher, Christopher Y.]

Sorry, LLILF only load bits 32 to 63, not 0 to 63. So, LLILF meets your requirement to load only 32 bits/

[Charles Mills]

Noooooooooooooooooo!

What do a senior z/OS developer and I have in common? We both got our butts bitten by this!

LLILF: "The second operand is placed in bit positions of the first operand. The remainder of the first operand is set to zeros."

Charles

[John Dravnieks]

There is always some method in the instructions.

All Load Logical instructions update the part of the register as asked
for, and then zero the rest of the first operand
(for example LLC - load logical character loads
the low order byte from the second operand and zeroes the rest of the
register)
All Insert Immediate instructions update the part of the register as asked
for - the rest of the first operand is left as is
(for example, IILL - the much older IC could be
considered as an Insert Immediate Character)
All Load instructions sign extend the second operand if required and use
that result to update the first operand.
(for example, LB - Load Byte - sign extends the
one byte second operand and updates the register with the result

Kind Regards

John

Internet: dr...@au.ibm.com