Re: Is TESTCB a bad boy ?

2020-10-26 Thread Christopher Y. Blaicher
I've seen examples where the "built" instruction was a non-reentrant location in the same CSECT and very near to the "build" instructions. Not my code, but I have seen it. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Christopher Y

Re: Is TESTCB a bad boy ?

2020-10-26 Thread Christopher Y. Blaicher
This will not have the same performance hit. The problem with the MVI was the CPU had to 1) bring the cache line into the data cache; 2) apply the MVI data; 3) refresh the cache line in the instruction cache; and finally 4) execute the instruction. Doing an EX skips steps 1, 2 and 3. EX has its

Re: Conditional MVCL macro?

2020-10-20 Thread Christopher Y. Blaicher
The first, base code, is just the following to get the overhead of loop control; TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM LOOPBDS0H L R3,POOLADDRGET FROM ADDRESS L

Re: Conditional MVCL macro?

2020-10-20 Thread Christopher Y. Blaicher
ERV.UGA.EDU] On Behalf Of Christopher Y. Blaicher Sent: Tuesday, October 20, 2020 2:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Conditional MVCL macro? This message originated Externally. Use proper judgement and caution with attachments, links, or responses. I just re-ran a test on

Re: Conditional MVCL macro?

2020-10-20 Thread Christopher Y. Blaicher
I just re-ran a test on our z15 machine and got interesting numbers. The $MVC was reasonably linear from start to finish. The MVCL has a big jump from 2K to 4K, but was also reasonably linear outside of that jump. It never caught up to the $MVC implementation. TEST TYPE = BASE CODE C

Re: Conditional MVCL macro?

2020-10-20 Thread Christopher Y. Blaicher
We just got a z15 and I have not tested MVCL vs MVC loop, but on all prior machines a MVC loop beat a MVCL up to about 32K. Over 32K MVCL is the way to go. In our environment we rarely are moving more than 32K. We built a $MVC macro with 3 parameters, destination, source and length and use th

Re: old code failing

2019-07-24 Thread Christopher Y. Blaicher
Maybe the system put the TIOT entry in the extended TIOT. Look up EXTRACT and GETDSAB macros. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of retired mainframer Sent: Wednesda

Re: Basic question on Procesors/Instruction set

2019-03-20 Thread Christopher Y. Blaicher
Look in the HLASM Programmer guide. There is an assembler option to tell it the level of machine you want it to validate the instructions against. You probably want the ZS-6 options, or OPTABLE(ZS6) Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainfr

Re: Instruction/Data Cache Usage (was EQU *)

2018-08-01 Thread Christopher Y. Blaicher
Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you ca

Re: BAKR Instruction

2018-05-29 Thread Christopher Y. Blaicher
ey replace, including allocating and freeing the save area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Christopher Y. Blaicher Sent: Tuesday, May 29, 2018 2:12 PM To: ASSEMBLER-LIST@listse

Re: BAKR Instruction

2018-05-29 Thread Christopher Y. Blaicher
A quick test of performance shows that BAKR/PR is about 14 times as expensive as STM/LM. I would say that in in initialization/termination code using BAKR/PR isn't going to hurt you, but I would totally avoid it in record level code. Chris Blaicher Technical Architect Mainframe Development P: 2

Re: Dr. John Ehrman

2018-02-21 Thread Christopher Y. Blaicher
A short poem for John. It was written by Barbara L. Smyth, a friend. And the sun set. It's not so much I fear the coming of the night, It's more I mourn the end of a beautiful day. Chris Blaicher Technical Architect Mainframe Development P: 201-930-8234  |  M: 512-627-3803     E: cblaic...@sync