Month: July 2012

  “Location, Location, Location”.  That old real estate mantra has a significant application to certain assembler programs.  If you’re writing programs that are I/O-intensive – programs that read hundreds of thousands of records, particularly those with large record sizes, then this old chestnut can help you cut your running times dramatically.  If you are fortunate, you may slash your running time in half, simply by making some small changes in your code.

   For years I never gave much thought to the difference between Move Mode I/O and Locate Mode I/O.  (If you’re not familiar with these two techniques you can check out an article that explains it here.)  Oh, I knew how to code both, but Move Mode was easier to teach, and delivered the goods right where you wanted them.  I knew that Move Mode records were being moved from a system buffer to my own storage, but I figured:  What’s an extra move or two among friends?  But I was wrong.  Working with companies that routinely process millions of records taught me otherwise.

   In Locate Mode, you can leave an input record in a system buffer and work with it directly.  On output, you locate an empty buffer and build your record there.  This simple technique works wonders if you are processing hundreds of thousands of large records.  The cool part is that it doesn’t take much refactoring of your code to switch over.  So if you are faced with processing hundreds of thousands of records, just remember:  Location, Location, Location.

You can write quite a bit of source code in assembler without generating much object code. I’m always surprised at how small the object modules are after all my hard work. While assembler programmers work at a very fine-grained level, with most of our thoughts broken down into many tiny pieces, the instructions we use are quite powerful. A good chunk of each program consists of data areas – no real code there. And then each hard-won instruction only generates two, four or six bytes. The small object modules we create are even more surprising when you realize that much of the code is produced by IBM macros like OPEN, CLOSE, GET and PUT.

Try this experiment: Add the directive PRINT ON,NODATA,GEN at the top of your CSECT. Re-assemble your module and look at the program listing. If your code is typical, you’ll see lots of new statements that your didn’t see before. These lines are prefixed with a “+” sign and make up the code of your macro statements. It’s likely that a healthy percentage of lines in your program were macro-generated. If you coded very many macros, your own work may seem to disappear into the background.

So … write away without hesitation, knowing there’s plenty of room for all your ideas.

It’s easy to spot the thinking of long-forgotten legacy assembler programmers in the production code that runs on today’s systems.  Working under the constraints of limited memory, these programmers developed techniques for making their code as small and as efficient as possible.  While we’re not as memory constrained as these early programmers, you’ll still find their old techniques being practiced in today’s shops.  When I code these old tidbits, I like to think of it as “tipping my cap” to programmers who came before me.  Here are some examples:

Decrementing a register:

BCTR   R5,R0

This is a simple way to subtract 1 from register five.  Coding 0 for the second operand causes the flow of control to continue with the next instruction.  We could just as easily have coded this:

S      R5,=F’1’

So, why was the first technique originally preferred?  BCTR is a register-to-register (RR) instruction and will run faster than the register-to-indexed storage (RX) version.  Also the second version requires the assembler to build a fullword in memory.  Today, we might not give a second thought to defining a field, but in 1964, every byte was precious.

Moving blanks to a field:

This technique has existed since the Ancient of Days.

Assume that field X is defined as below:

X     DS    CL80

The following code will move blanks to X :

MVI      X,C’ ’

MVC      X+1(L’X–1),X

The MVI fills the first byte with a blank, and the MVC propagates blanks, one byte at a time, from left to right in field X.  The length attribute L’X gets the assembler to plug in the correct length.  Today we might code this without thinking:

BLANKS   DC   CL80’ ’

…

MVC    X,BLANKS

This technique requires an 80 byte field that the first method does not.   But, what’s a few bytes among friends?

Loading a “small” number into a register:

This code will put 100 in register five:

LA     R5,100

What’s going on here?  The assembler is looking for a base/displacement and perhaps an index register for creating the address that will be loaded into the register.  Everything is explicitly coded and there are no parentheses.  Explicit addresses look like this – D2(X2,B2) – that means the only thing the 100 can represent is a displacement.  The base and index registers are assumed to be zero, and therefore don’t contribute to the effective address.  If you use this technique, you are limited to a maximum value of 4095 – the maximum displacement that will fit in three hex digits.  So why not just code this instead?

L        R5,=F’100’

Well … that works fine, but again, our “modern” technique requires the assembler to build a fullword field that isn’t needed with the first method.

Do you have a favorite legacy technique I’ve missed?  Let me hear from you.

Most programmers rarely give a second thought to the bit patterns their compilers generate.  After all, they don’t need to.  Compilers have freed them from the low-level details of ones and zeroes.  If you are a Java programmer, the JVM has converted your box to a virtual Java machine.  It’s a convenient and effective abstraction that allows you to develop wonderful things.

Still … there is a fundamental appeal to writing assembly language, clearing away the virtual cloud, and working with bits and bytes directly, and without a net.  At the assembly level, it’s crucial to pay attention to all the ones and zeroes.  In fact, paying attention to ones and zeroes is the way forward … the way to get a grip on the hundreds of instructions that are available to you as an assembler programmer.

Assembler instructions fall naturally into groups based on the binary pattern of each instruction.  This pattern is called an “Instruction format”.  For example the MVC (Move Character) instruction belongs to a group of instructions called “Storage to Storage”.  Specifically, MVC is Storage to Storage, type one (SS₁).  Here’s the format, bit by bit:

Bit 0 – 7                 |  The operation code

Bits 8 – 15           |  The length associated with operand 1

Bits 16 – 19         | The base register for operand 1

Bits 20 – 31        | The displacement for operand 1

Bits 32 – 35       | The base register for operand 2

Bits 36 – 47       | The displacement for operand 2

Suppose you had coded MVC   X,Y  and  you saw the assembled instruction in memory presented in a hex format:   D2 03 C0 04 C0 08 .  The D2 is the operation code for MVC.  The 03 represents the length (really the length – 1) associated with operand 1. C004 is the base/displacement address of X, and C008 is the base/displacement address of Y.  This is a fairly boring array of information, yes?  Perhaps so, until you realize that this is the only information presented to the CPU when it’s time to execute the instruction.

So what information does the CPU know about your instruction at execution time?

• The operation – MVC
• The number of bytes associated with X.  (This length may or may not match the actual length of X!)
• The beginning address of X
• The beginning address of Y

And what exactly doesn’t the CPU understand about y your instruction?

• The ending address of X
• The ending address of Y
• The type of information stored in X or Y
• Whether X and Y will overlap if the operation is repeated for the specified length

What’s really interesting and helpful is that lots of instructions fall into the SS₁ instruction format.  The facts you learned above apply to all the instructions in this group.  Knowing an instruction is SS₁ is half the battle to learning how the instruction works.

So here’s my plan.  Early on, learn the following instruction formats:  SS₁, SS₂, SI, RS, RX, and RR.  There are other types, but these six types will carry you a long way into this journey.

I’ve developed a software product called VisibleZ that will also help you on this journey.  VisisbleZ was written in Java, and is an object code emulator for IBM mainframes that will help you visualize instructions as you single step through object code programs.  It will also help you learn each instruction type.  You can download the product from the product homepage:   http://csc.columbusstate.edu/woolbright/visiblez.xml .

You will also find a series of lessons that will help you get started.  Start with the lesson called “Reading Objectcode” and you’ll soon be an expert on the six instruction formats mentioned above.