So to continue with your example, the question is would this code prove more or less efficient:
DO UNTIL=M VLL V1,R15,0(R1) VFEEB V1,V1,V0,M0 VLGVG R14,V1,7 ** THE QUESTION AT HAND IS HOW EXPENSIVE IS THIS INSTRUCTION COMPARED WITH SETTING THE CC IN VFEEB CHI R14,15 ** IS RESULTING INDEX VALUE LESS THAN 15? DOEXIT 4 ** ASSUMING 4 = FIRST OPERAND LOW, CC = 1 FROM CHI AGHI R15,-16 LA R1,16(,R1) ENDDO , Although that may not be quite correct. What if the last byte (15) matches? Or am I misunderstanding what happens in the none-found case? Peter -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Ed Jaffe Sent: Saturday, June 16, 2018 9:23 PM To: [email protected] Subject: Re: Count Words? On 6/16/2018 5:53 PM, Farley, Peter x23353 wrote: > The PoP says for the Vector String instructions that "For all instructions > that optionally set the condition code, performance may be degraded if the > condition code is set." > > Have you found that performance can be significantly (or at all) improved by > not setting the CC in the SIMD instruction and just always extracting the > seventh byte of operand 1 to see what is the resulting index value in a > regular GR? GREAT QUESTION! We have not experimented with that yet. So far, in every case where we expect the cc to be set, we are checking it right away for example: DO UNTIL=M VLL V1,R15,0(R1) VFEEB V1,V1,V0,M1 DOEXIT 4 AGHI R15,-16 LA R1,16(,R1) ENDDO , Note that the DOEXIT immediately follows the VFEEB. Despite not seeing such cases in our code, I would speculate that if we had a situation where we could defer checking of the cc until later (or not check it at all!), it would make perfect sense to do so. -- 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.
