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
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: [email protected]
Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware
Why write two lines when one will do the job?
Hmmm. Clarity comes leaping to mind as a pretty good reason.
At 10/16/2017 10:10 AM, Blaicher, Christopher Y. wrote:
Robin,
It depends on if you are doing it once per job
(who cares), once per record (well maybe) or
once per field (yea, I'm interested).
Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234Â |Â M: 512-627-3803Â Â Â
E: [email protected]
Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com
Data quality leader Trillium Software is now a part of Syncsort.
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:[email protected]] On Behalf Of Robin Vowels
Sent: Monday, October 16, 2017 10:03 AM
To: MVS List Server 2 <[email protected]>
Subject: Re: One Byte MVC Versus IC/STC
From: "David S." <[email protected]>
Sent: Thursday, December 17, 2015 6:10 AM
>> > "... a good reason why small MVCs run slower than LG/STG pairs ...
>> > overhead at the beginning of an MVC ... check if the operands are
>> > on
> 'good'
>> > boundaries ... check for operand overlap ... length check ...
> [meanwhile] the
>> > LG/STG is far on its way. Anyone writing a length-1 MVC instead
>> > of an IC/STC would be laughed out of their code review.
>>
>> Rubbish.
>> KISS.
>> A move of length 1 is clear and unequivocal.
>> And it's only one line.
>
> Nevertheless, IC/STC is what the newer mainframe compilers generate
> for a one-byte move. For the reasons given, it's less work for the
> system than an MVC.
It's a question of what is easiest and simplest for the programmer.
Machines are supposed to do the work for us, not the other way around.
Why write two lines when one will do the job
