John, I have to take exception to your comments on speed vs style, at least with as broad a brush you painted it with.
I have often said that code written for use in one-time routines (initialization, termination, error processing) should be clear and code in performance routines (run one or more times per record) should be written for speed. A 60% gain using 'loops of older hardware ones' is well worth the effort. If the break-over point for TRTR is strings over 1000 bytes and the largest you expect is 128, then it would be very wasteful to use the TRTR, even though it is one instruction rather than several. The instruction set is not what is going to make or break the mainframe. Most application coders never see the real instructions. They are using a higher level language. Most of us on this list are writing performance code. The overhead to use millicode instructions is just too great in many cases. Compare a pair of MVC instructions to move 512 bytes to a MVCL to move the same 512 bytes. The difference is startling. Yes, I use MVCL, TRT, CLCL and the rest of the millicoded instructions, I just use them where appropriate. Christopher Y. Blaicher Senior Software Developer BMC Software, Inc. Austin Development Lab phone: 512.340.6154 mobile: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of john gilmore Sent: Friday, October 08, 2010 9:13 AM To: [email protected] Subject: Re: TRTR Of my suggestion that this instruction be used to locate the rightmost non-blank in input text Peter Farley wrote > > Useful, yes. CPU efficient, not. > The TRTR is a relatively new instruction, and I should be prepared to stipulate that it is now slower than constructs that use CLCs in loops. I doubt that it will remain so, but that is not my point here. The use of a TRTR is here more perspicuous; and attempts to replace single millicode-based instructions with loops of older hardware ones are, I think, perverse. A good programming style, like a good prose style, is preoccupied with lucidity, force, and ease, and not with this sort of thing. On, say, a millisecond IBM 650 they made some sense; on a nanosecond zArchitecture machine they make none. Retreating into the familiar is easy, too easy. Attention to such 'problems' just does not help to give this platform a future. John Gilmore Ashland, MA 01721-1817 USA
