Month: June 2012

   You’ve taken the plunge.  You’re familiar with the organization of memory, the PSW contents, the purpose of Registers, and the fetch/decode/execute cycle.  You understand the idea behind base/displacement addresses as a way to find an item in memory.  Now What?  What is the best way forward?

   The best strategy is to tackle instructions in groups, organized by data type, and the simplest group of instructions contains those that work on character data.   It’s harder to cause pesky abends when you are just moving character data from here to there, or comparing a couple of fields and branching based on the condition code.  As instructions go, character data instructions are also pretty straightforward – a great place to start.  So here’s the plan:  

1)  Character Data – Learn to define character fields and data here.

2)  Character Instructions – Read about MVC (Move Characters), CLC ( Compare Logical Characters), MVI (Move Immediate) and BC (Branch on Condition).

3)  Jumping in the Water – Listen to the beginning assembler videos that will show you how to build and submit a simple program:

• Introduction to Assembler Language
• SS1 Instructions, MVC, CLC, MVI
• MVI, DCB, Open, Close, Standard Entry and Exit
• A First Program
• Removing Assembly Errors in the First Program

4)  Packed Decimal Data and Instructions – When you are comfortable working with character data, tackle packed decimal data and the instructions that support it (PACK, UNPK, ED, ZAP, AP, SP, DP, MP, SRP, CP).

5)  Binary Data and Instructions – Move on to Binary data and learn to program instructions that work in the registers.  Start with L, LA, ST, A, S, M, D, C, AR, SR, MR, DR, LR, CR, SRDA.) 

6)  Name and Conquer –   Dummy sections (DSECTs) provide an assembler programmer the ability to use symbolic names to address any storage area.  This turns out to be a powerful idea – name and conquer!  Read about DSECTs and how they are commonly used.

7)  Divide and Conquer – For large projects, programmers divide the problem at hand into multiple programs that are easier to code and understand.   In order to make our programs work together, it’s important to learn the established linkage conventions for calling other programs, and for passing data back and forth.

8)  Go Exotic –  There is a collection of instructions that are invaluable when needed, but aren’t as commonly coded as the instructions mentioned above.  These instructions include TR, TRT, TM, MVCL, CLCL, and EX.  Take them one at a time and find out how each one is valuable.

9)  Keep It Up – There’s no substitute for writing code.  In a future post, I’ll highlight a series of assignments that will make you code all the instructions described above.  By the time you’ve coded the last program, you’ll be able to call yourself an assembler programmer. 

Here’s a daunting thought for anyone starting to learn IBM assembly language:  The latest System/z machine executes over 500 machine instructions.  Where on earth should you start if your goal is to become proficient?   As in many subjects that are complicated (think mathematics, physics, chemistry), taking a historical approach to their study is often helpful, and while there is no royal road to assembly language, going back to the roots of any subject can be illuminating.  

  The roots of IBM System/z assembly language started with the System 360 in 1964.  This historic machine was equipped with an instruction set that was much smaller than current models.  Ignoring privileged instructions (those that require special authority), and floating point operations altogether (business arithmetic occurs in packed decimal), the instruction set that is left over numbers around 100.  Another happy fact of learning assembly language is that by mastering a single instruction, you will learn several others by association.  We are left with a manageable instruction set of fifty or sixty instructions that make up a working subset – a subset that can make you marketable. 

   So where do we begin?  Here’s a plan that will ease you into assembly language:

1)  The Lay of the Land – Start with a general orientation to the machine and the components you will interact with as a programmer here.

2)  Location, Location, Location  – Every variable you create in assembly language is converted to a Base/Displacement address.  In a high-level language, we don’t usually worry about the exact location of variables, but in assembly language it’s critical.  Read about base/displacement addressing here and give it your full attention.  Alternatively, you can listen to the beginning assembler video tutorials on my website.

3)  Ground Zero – Every displacement is measured from a specific point in memory called the “base address”.  This address is loaded into a register – the “base register”.  The combination of the base register and the displacement is used to identify where a variable lives in memory.  The instruction which establishes the base address and loads the base register is called BASR (BALR is an older similar instruction).  Look up IBM’s manual called Principles of Operation on the web and read about BASR.  While you are there, check out  MVC, CLC, and BC.

4)  See It Happen – Download the VisibleZ software from this site.  VizibleZ is a java-based object code interpreter that is designed to help you visualize assembly programs and the effects they have on system components.  After reading the article on instruction formats here, load the mvc.obj program that is distributed in the Codes directory.  Single step through each instruction.  Pay close attention to the base displacement addresses in each instruction.   Do they make sense?  The color coding in the product should help you figure it all out.

  At this point, you’re on your way.  It’s a long journey, but an interesting one, particularly if you like to program, you would rather do things yourself, in your own way, and you like laying code down directly on top of the metal.    

Among other things, you need a sense of humor to be an assembler programmer, as the language presents you an unlimited number of opportunities for shooting yourself in the foot.  (Programmers think a lot about shooting themselves in the foot because it happens so often.)  Here are three ways to do just that in languages I’ve been using lately:

Assembly
You try to shoot yourself in the foot only to discover you must first reinvent the gun, the bullet, and your foot.  After that’s done, you pull the trigger, the gun beeps several times, then crashes.

370 JCL
You send your foot down to MIS with a 4000-page document explaining how you want it to be shot.  Three years later, your foot comes back deep-fried.

Java
After importing java.awt.right.foot.* and java.awt.gun.right.hand.*, and writing the classes and methods of those classes needed, you’ve forgotten what the hell you’re doing.

It seems that shooting our feet (It’s never just the one foot, is it?) is inevitable, and it’s easy enough to do with L or LA.  So, what exactly is the difference between Load (L) and Load Address (LA)?  Both instructions compute the address of operand 2.  LA simply puts the address in the operand 1 register.  But L, retrieves a fullword from memory – the one designated by the computed address – and puts that fullword in operand 1. But you probably already knew that.

There is another answer to this question that occurred to me in graduate school some thirty years ago.  I was struggling to fix the code for a multi-user mainframe operating system I was building.  It came to me in the form of a joke:

Question: What is the difference between Load and Load Address?
Answer: About a week’s work of debugging.

So now, whenever I code L or LA, I pause and give it an extra thought.  Over the years it’s a habit that has saved me many weeks of debugging.  It can help you, too.  In the heat of the battle, it’s tempting to just let the code fly and test later… after all, it’s all good, eh Joe?  But take my advice. Whenever you code, L or LA, take a sip of your favorite beverage, relax, and give it one extra thought.  Is it L or LA?  The answer is more important than you think.