Novices Guide to Assembler - Part II

8/3/2019 Novices Guide to Assembler - Part II

1/6


2/6

coding technique which gets around this problem. An unchangeable program canacquire dynamically obtained storage, just for this run, which will contain all of thechangeable data. The rest of the program will remain completely unaltered throughout therun. Writing a program in such a way, is called making the program reentrant.

Making a program reentrant requires the use of system services to acquire the dynamicstorage needed to contain the changeable data. In an MVS system, the service ofobtaining storage is called GETMAIN. Oppositely, the service of freeing acquired mainstorage is called FREEMAIN. The GETMAIN and FREEMAIN services are invoked bysystem assembler macros. These macros, in their expansion, generate SVC (SupervisorCall) instructions. There are several different SVCs that a GETMAIN or FREEMAINmacro can generate. Which SVC is called, depends on what parameters are coded in theGETMAIN or FREEMAIN macro. In higher level MVS systems (ESA), there is also aSTORAGE macro that can be used by a program to dynamically obtain additional storageareas for the programs use.

There is one more thing we have to say about reentrancy.

Suppose a program is indeed written so it does not modify itself. The system, however,will not force the use of a single copy of this program, unless the program also has theRENT (reentrant) linkage editor attribute turned on. That attribute is a bit setting in thepds directory entry for the load module, which was set by the linkage editor at the time theprogram was linkedited. This is done by coding a parm of RENT in the linkage editor JCL.The RENT linkage editor attribute tells the program fetch service to set things up, so thatmany callers of this program will use only one actual copy.

How do we write a re-entrant program? Remember from last month, that when a normalapplication program is run under MVS, it is called by a chain of perhaps eight or nine otherprograms. Register 13 comes in, pointing to the previous programs register save area.

In any program, the register save area will contain variable data. So before establishing anew save area for our program, we GETMAIN enough additional storage to contain the 72bytes of the register save area, followed by all the storage needed to contain all thevariable data which the program will have. If the save area is placed at the beginning ofthis dynamic storage, we can point Register 13 there, and do a USING on Register 13 tobe able to find all of the fields in the dynamic area. Just before our programs execution isabout to end, after Register 13 is restored to point to the calling programs save area, ourprogram does a FREEMAIN of the dynamic storage, to give it back to the operatingsystem. You can see a coded example in Figure 1.

ASSEMBLER MACROS AND DSECTS.

The Assembler (which is a compiler for assembler language code) normally generatesonly one machine instruction for each instruction that was coded by the programmer. Sowhy do we need a compiler if we are really coding in machine language, one generatedinstruction per coded instruction?

There are several reasons for this. First, the Assembler instructions are pseudo-English,whereas the machine instructions are merely hexadecimal numbers. It is a lot easier toremember something that looks like a language. Second, the Assembler does thearithmetic for us. If we tell the program to branch (jump) to a certain location, we can code

the target location as a label, and the Assembler will calculate the location to which theprogram has to go. This is just one of many examples in which the Assembler makes our


3/6

coding easier by doing a calculation. Third, the Assembler contains a Macro Facility,which allows the generation of a complicated result from the coding of just one macroinstruction that can have options and switches built into it. The GETMAIN and FREEMAINmacro instructions, which obtain and free storage for a programs use, are examples ofmacro instructions. See Figure 2 for a sample of the kind of code these macros generate.

Macro instructions can be pictured as coded mini-programs which perform a specificfunction. The source code for each macro starts with a MACRO statement and ends witha MEND statement; almost any kind of assembler statements may be coded in between,including other macro statements. In an assembler program, a macro is as though it werean instruction. When the program is assembled, the Assembler will realize that the macrois not part of the regular instruction set, and it will try to find the macro source code, eitherinline together with the program source, or externally in a macro library. The macrolibraries are pointed to by the SYSLIB ddname in the assembly JCL. IBM supplies largecollections of macros for its own use and for programmer use. Many of the IBM macrosare shipped in two libraries: SYS1.MACLIB and SYS1.MODGEN.

Informally, one might say there are various categories of macros. Some, like GETMAINand FREEMAIN, are designed to invoke a system service. Others, which can be termedmapping macros, contain data patterns which subdivide data areas into individual fields.A third type of macro is similar to a subroutine. You can input some keywords into themacro, and it will return a result. Actually, one can code almost anything in between theMACRO and MEND statements, so macros have an enormous amount of flexibility, bydefinition. Macro coding often makes extensive use of what is called conditionalassembly. Assembly-time branches, switches, and changes of variable may be built intothe structure of the macro source. This allows macros to have enormous power andflexibility. Conditional assembly is discussed in detail in the Assembler Languagemanuals for the various IBM assemblers.

In our treatment today, we only have time to discuss the mapping macros, so we willintroduce the concept of the DSECT, or Dummy Section of a program. DSECTs map outpatterns of storage, without actually defining a piece of the executable section of theprogram. For example, suppose we are dealing with a 20-byte record, which is dividedinto fields of various sizes and kinds. We can code a DSECT which will map the recordlayout of our record. Then we can load a register with the actual address of where therecord is. A USING statement containing the label of the beginning of the DSECT, andthe register in which the beginning of the data is loaded, will allow the program tosubsequently address any of the individual fields in the data record.

Storage in an assembler program is defined either with the DS (Define Storage)instruction or the DC (Define Constant) instruction. DS will define a certain amount ofstorage, with a certain length attribute, but will not specify the actual data values which areloaded into that place. DC, in addition to that, defines the initial value of the dataoccupying the storage which has been defined. There are many details concerning thekinds of storage which one can define. This matter is explained in the IBM AssemblerLanguage manuals. For now, we can explain that hexadecimally expressed storage isindicated by the letter X, EBCDIC character form is indicated by the letter C, and binary bitform is indicated by the letter B. See Figure 2, which shows some storage definitions.

Control blocks defined in the MVS operating system, are usually mapped by IBM-suppliedmacros which define DSECTs. A USING statement referring to a specific area (often the

beginning) of the control block, and connecting to a register, which has been loaded withthe address of that area in virtual storage, will allow a program to specifically refer to all


4/6


5/6

MVC MESSAGE(20),MSGLINE MOVE TEXT TO VARIABLE AREAMVC MESSAGE+13(7),PSCBUSER MOVE MY USERID INTO MESSAGEDROP R3TPUT MESSAGE,L'MESSAGE DISPLAY THE WHOLE MESSAGE ON THE

TUBE

RETURN DS 0HLR R1,R13 SET UP FOR SAVEAREA FREEMAINL R13,4(,R13) POINT TO CALLER'S SAVEAREAFREEMAIN RU,LV=DATALEN,A=(R1),SP=SP000LM R14,R12,12(R13) RELOAD THE CALLER'S REGISTERSBR R14 RETURN TO CALLER

MSGLINE DC CL20'MY USERID IS ' CONSTANT PART OF MESSAGE*SAVEAREA DSECT

DS 18F DEFINE MY SAVEAREA - 18 FULLWORDSMESSAGE DS CL20 VARIABLE MESSAGE AREA

DS 0D ALIGN ON DOUBLEWORDDATALEN EQU *-SAVEAREA DEFINE LENGTH OF VARIABLE STORAGE*

CVT DSECT=YES CVT mapping macroIKJTCB TCB mapping macroIEZJSCB JSCB mapping macroIKJPSCB PSCB mapping macroEND

* * * * * * * * * * * * * * * * * * * * * * *

Figure 2. One instance of the expansion of the GETMAIN macro. In this example, weare requesting that the system acquire unconditionally, an amount of storage representedby the numerical value in the variable DATALEN. We also ask that the location of thisvirtual storage be at addresses below the 16 megabyte storage line, i.e. that its numericaddresses be less than the hex quantity X00FFFFFF. This is followed by an expansionof the corresponding FREEMAIN macro. The variable SP000 has been equated to zero,so the obtained storage will come from Subpool 0. The plus signs to the left, show the

lines of code that are generated when the Assembler expands the macro code.

GETMAIN RU,LV=DATALEN,SP=SP000,LOC=BELOW+ CNOP 0,4+ B *+12-4*0-2*0 BRANCH AROUND DATA+ DC A(DATALEN) LENGTH+IHB0001F DC BL1'00000000' Flags+ DC AL1(0) RESERVED+ DC AL1(SP000) SUBPOOL+ DC BL1'00010010' MODE BYTE+ L 0,*-8+2*0 LOAD LENGTH+ L 15,IHB0001F LOAD GETMAIN PARMS


6/6

+ SR 1,1 ZERO RESERVED REG 1+ SVC 120 ISSUE GETMAIN SVC

FREEMAIN RU,LV=DATALEN,A=(R1),SP=SP000

+ CNOP 0,4+ B *+12-4*0-2*0 BRANCH AROUND DATA+ DC A(DATALEN) LENGTH+IHB0013F DC BL1'00000000' Flags+ DC AL1(0) RESERVED+ DC AL1(SP000) SUBPOOL NUMBER+ DC BL1'00000011' MODE BYTE+ L 0,*-8+2*0 LOAD LENGTH+ LR 1,R1 LOAD AREA ADDRESS+ L 15,IHB0013F LOAD PARAMETERS+ SVC 120 ISSUE FREEMAIN SVC

Novices Guide to Assembler - Part II

Documents

Transcript of Novices Guide to Assembler - Part II