Thanks for the story. I started writing assembler in 1967 on early serial of 360/75 (machine 3 or 4) by reading fortran generated code.
I also focused on efficiency. My typesetting program ran 10 times faster then its competition. A programmer at Dept of Commerce complained my output module for Termtext was a ripoff because it ran at the same speed as a file copy. One point about the future. If assembler is to be relevant to the future, it must be by using macros. Whenever I have to do a repetive task, I write either a macro or a subroutine, or both. richard peace be with you -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of David Cole Sent: Monday, October 16, 2017 12:24 PM To: [email protected] Subject: The Pointlessness of handwriting "efficient" code (was One Byte MVC Versus IC/STC) First, let me start by saying I am NOT talking about the kernel of sorting routines intended to sort records by the millions. Nor am I talking about any similar place where saving a few nano-seconds here and there might actually matter. If that's your concern, then this post is not for you. I am talking about typical logic whose execution frequency ranges from a handful per week all the way up to maybe a million times per hour. (Just guessing here, but it sounds good.) I'm also talking about hand coded Assembler. If you want to write efficient code, use a compiled language. Use C. Use Cobol. Use whatever. But don't use Assembler. Assembler is probably the worse language to choose. Why? Well, read on. I started writing assembler back in the late 1960s. I've been writing assembler for nearly 50 years. I've written a LOT of assembler, and I still love writing it! Back when I started, one of my coding ethics was "efficiency", both in space and time. I wanted my programs to accomplish as much as they could with the fewest instructions taking up the least number of bytes as possible. (That, of course led to some gawdawful code being written!) Well, back in that day, when a large machine had maybe a half a meg of storage, and megabyte storage frames literally had to be wheeled in on trucks, program size actually did matter. And with storage access speeds measured in micro seconds (and even milliseconds for the LCS storage), speed mattered too. But those days are long gone, and I have long since grown out of my childish ways. Yes, speed does matter, and IBM has invested an immense amount of expertise and creativity to come up with ways to leverage parallelism and pipelining and only god knows what all else to squeeze out every unneeded nanosecond of processing time it can. It is statistics based and it is mind-numbingly complex. Any given combination of workflow will never behave the identically same way one run to the next. (Even though statistically speaking, efficiencies will be repeatable.) But all these techniques for efficiency that IBM has created are not human compatible. They are too complex, they are too messy[!] and they are not even the same techniques from one machine to the next. In fact, sometimes code written to be efficient on one machine will be actually inefficient on another! In other words, if you are using hand-coded Assembler, and you want to write the most efficient code possible, you will end up writing something... - That is messy, - That is ugly, - That will be difficult to read, follow and understand, - That will probably fail to be the most efficient possible, - And that you will probably have to rewrite when IBM comes out with its next machine. So if there is anything that needs to be "Laughed out of code review", it's feeble concerns with such questions as MVC-onebyte vs. IC/STC. As a prior gentleman commented, "rubbish!" The point is, with code written in any language (especially for production program development), one of the most important ethics is clarity, because without that, the code will not be maintainable over time. (www.colesoft.com/files/presentations/commercialqualityprogramming.pdf) Obscure code is what should be laughed out of code review, and serious attempts to write so called "efficient" code (a) will fail to produce perceptible results and (b) will only end up obfuscating the code. So if all these wonderful efficiency techniques that IBM has come up with are too complex/obscure/ugly to use, then what's the point? COMPILERS! That's the point. Let the compilers be concerned about efficiency. That's their job. That's what they do far far better than humans. When IBM develops new pipelining techniques and new methods to achieve better parallelisms, they don't do it in a vacuum. They get their compiler writers involved! There is a back-and-forth between the two teams: Between the hardware developers and the compiler writers. Together, they hammer out what will work and what won't. In the end, the compilers are fitted to the hardware, and the hardware is fitted to the compilers. Another thing... Did you know that as of the Z14 machine, the Principles describes 2,024 separate machine instructions? Did you know that if you throw in Extended Mnemonics, that comes to 2,144? Here's my questions. If you are an Assembler programmer, how many of these do you use more than just for special occasions? (In my case, its maybe a couple of hundred at most.) Do you really think that you're really going to write the most efficient code possible using just the instructions you're most comfortable with? Well, maybe you and I won't be using the full instruction set anytime soon, but you can be damn sure the compilers will! In recent years, IBM has gone to town creating new machine instructions, and if you glance over them at all, you will note that a lot of them were specifically developed to increase execution efficiency. (The several Compare/Load and Trap instructions are just one group that comes to mind as obvious examples of this.) So if you really want to write the most efficient code possible, you will use C, or you will use Cobol, but you will never use Assembler! Don't get me wrong. Assembler does have its uses, but contrary to more, efficiency no longer os one of them. Dave Cole ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
