help for new assembly'er 
Author Message
 help for new assembly'er



Quote:

>My girl friend starts to working with system 370 assembler.
>But she don't care syntax and rules of 370 assembly !

There are really very few bad practices in 370 assembler, or perhaps
there are really very few good practices in 370 assembler.  Now that
I sound confused too, let me lay down a few rules, of thumb that is.

Since registers zero, one and two can be modified by everything from
SVCs to TRTs, use them for scratch areas.  R15 is your entry address
but you should save it off - R12 is typically used for this and thus
as the code base register.  R14 is the return address but can be used
within your code as can R15, as the OS never really relies on them.
R13, on the other hand, should always point to your Register Save
Area, unless you are working with DOS/VSE/POWER, in which case I
commend your soul to the appropriate power.

Always observe register saving and save area chaining scrupulously.
That is, use the SAVE and RETURN macros or write code yourself to
put R14-R12 at 12(R13), then save the address of your area in the
caller's area and save hers in yours.  Note:  a calling process is
generally called the `mother' process.

All other registers can be used for base or scratch as you like.
Writing reentrant code (use RU-type GETMAIN for all data areas)
is good practice but not much good otherwise.

Always use DS 0H for all branch labels.  There was a much better
reason once (in the days of punch-cards) but now it just helps to
clarify the scene.  Never write self-modifying code - there is
always a better way to accomplish the same thing, generally with
a table of things to pick up and EXECUTE with, if your program is
so constituted.

Have fun.

--
Laird J. Heal                           The Usenet is dead!



Sun, 15 Aug 1993 12:32:34 GMT  
 help for new assembly'er

Quote:

>My girl friend starts to working with system 370 assembler.
>But she don't care syntax and rules of 370 assembly !  

There are really very few bad practices in 370 assembler, or perhaps
there are really very few good practices in 370 assembler.  Now that
I sound confused too, let me lay down a few rules, of thumb that is.

Since registers zero, one and two can be modified by everything from
SVCs to TRTs, use them for scratch areas.  R15 is your entry address
but you should save it off - R12 is typically used for this and thus
as the code base register.  R14 is the return address but can be used
within your code as can R15, as the OS never really relies on them.
R13, on the other hand, should always point to your Register Save
Area, unless you are working with DOS/VSE/POWER, in which case I
commend your soul to the appropriate power.

Always observe register saving and save area chaining scrupulously.
That is, use the SAVE and RETURN macros or write code yourself to
put R14-R12 at 12(R13), then save the address of your area in the
caller's area and save hers in yours.  Note:  a calling process is
generally called the `mother' process.

All other registers can be used for base or scratch as you like.
Writing reentrant code (use RU-type GETMAIN for all data areas)
is good practice but not much good otherwise.

Always use DS 0H for all branch labels.  There was a much better
reason once (in the days of punch-cards) but now it just helps to
clarify the scene.  Never write self-modifying code - there is
always a better way to accomplish the same thing, generally with
a table of things to pick up and EXECUTE with, if your program is
so constituted.

Have fun.

--
Laird J. Heal                           The Usenet is dead!



Sun, 15 Aug 1993 12:32:34 GMT  
 help for new assembly'er
On Wed, 27 Feb 91 04:32:34 GMT Laird J. Heal said:

Quote:
>Since registers zero, one and two can be modified by everything from
>SVCs to TRTs, use them for scratch areas.  R15 is your entry address
>but you should save it off - R12 is typically used for this and thus
>as the code base register.  R14 is the return address but can be used
>within your code as can R15, as the OS never really relies on them.
>R13, on the other hand, should always point to your Register Save
>Area, unless you are working with DOS/VSE/POWER, in which case I
>commend your soul to the appropriate power.

Please note that at least in OS/MVT and VS/1 and (presumably) the
various MVS variants, and the OS Simulation routines under VM/CMS,
that the various QSAM I/O macros (such as GET and PUT), involve
a  BALR  14,15  - so these registers should *not* be used except as
scratch unless you *know* that any system macros you use don't modify
these registers.  Incidentally, macros like this are the *REASON* you
usually use R12 as the base rather than R15....

                                  Valdis Kletnieks
                                  Computer Systems Engineer
                                  {*filter*}ia Polytechnic Institute



Mon, 16 Aug 1993 01:32:59 GMT  
 help for new assembly'er

   ...

Quote:
>Always observe register saving and save area chaining scrupulously.
>That is, use the SAVE and RETURN macros or write code yourself to
>put R14-R12 at 12(R13), then save the address of your area in the
>caller's area and save hers in yours.  Note:  a calling process is
>generally called the `mother' process.

In OS the common entry sequence is...

MODULE   CSECT
         SAVE  (14,12),,*
         LR    R12,R15                   (OS PROVIDES MY ENTRY POINT IN R15)
         USING MODULE,R12
         LR    R2,R1                     PRESERVE PARM POINTER ACROSS GETMAIN
         GETMAIN R,LV=SVLENGTH           MINIMUM LENGTH IS 72 FOR A SAVE AREA
         ST    R13,4(,R1)                BACK-CHAIN NEW TO OLD SAVE AREA
         ST    R1,8(,R13)                FWD-CHAIN OLD TO NEW SAVE AREA
         XC    8(4,R1),8(R1)             CLEAR FWD CHAIN OF NEW SAVE AREA
         LR    R13,R1                    OK -- SAVE AREA ALL SET UP

Quote:
>All other registers [besides 0, 1, 2, 13, 14 and 15]
>can be used for base or scratch as you like.
>Writing reentrant code (use RU-type GETMAIN for all data areas)
>is good practice but not much good otherwise.

Actually R2 is not used by any usual operating system functions, so
it's safe too (though the TRT instruction does use it as an implicit
operand).

Reentrant code is not that hard to do, and besides being good practice it
is critical if you ever use multiple tasks.  An easy way to arrange the
data areas is to make your save area (gotten above via GETMAIN) include
them after the register save area.  E. g.,

         USING R13,SAVEAREA

   ...

SAVEAREA DSECT
         DS    18F                      STANDARD OS SAVE AREA
<writable data areas go here>
SVLENGTH EQU   *-SAVEAREA               TOTAL LENGTH OF GETMAIN'ED AREA

You also need to learn about the MF=E forms of the MACROs -- what it
amounts to is that the standard forms of some MACROs don't generate
reentrant code because they have to create some kind of parameter list,
so they put it directly in the code and branch around it.  Those MACROs
all provide an MF=L form to generate the parameter list (as a constant)
and an MF=E form to fill it in and execute the operation.  You copy
the MF=L list into your work storage (again, in the GETMAIN'ed area)
and use MF=(E,<area>) to point to it.

Quote:
>...  Never write self-modifying code - there is
>always a better way to accomplish the same thing, generally with
>a table of things to pick up and EXECUTE with, if your program is
>so constituted.

Amen!

-----

(other points)

Note the use of symbolic names R<n> for the registers.  This helps because
it causes register references to appear in the cross-reference listing
generated by the assembler.  In a complex piece of code it can be
difficult to follow the register usage; having a listing can help this.

A related point:  pick a convention for your use of the registers,
document it in comments in the beginning of the routine, and STICK TO IT!
There is nothing more difficult than keeping track in one's mind of
the meaning of all the registers.  LOTS of bugs come from failing
to notice some subtlety in this area.

Finally, remember that no matter how well you write assembler code
it is almost always easier to write (and debug!) in a high-level language.
If what you are doing requires the use of assembler (e.g., because you need
to access some system interface that is only available from assembler),
a good approach is to write a small, well-defined subroutine in assembler
that can be called from a high-level language.



Mon, 16 Aug 1993 01:37:11 GMT  
 help for new assembly'er

   ...

Quote:
>Always observe register saving and save area chaining scrupulously.
>That is, use the SAVE and RETURN macros or write code yourself to
>put R14-R12 at 12(R13), then save the address of your area in the
>caller's area and save hers in yours.  Note:  a calling process is
>generally called the `mother' process.

In OS the common entry sequence is...

MODULE   CSECT
         SAVE  (14,12),,*
         LR    R12,R15                   (OS PROVIDES MY ENTRY POINT IN R15)
         USING MODULE,R12
         LR    R2,R1                     PRESERVE PARM POINTER ACROSS GETMAIN
         GETMAIN R,LV=SVLENGTH           MINIMUM LENGTH IS 72 FOR A SAVE AREA
         ST    R13,4(,R1)                BACK-CHAIN NEW TO OLD SAVE AREA
         ST    R1,8(,R13)                FWD-CHAIN OLD TO NEW SAVE AREA
         XC    8(4,R1),8(R1)             CLEAR FWD CHAIN OF NEW SAVE AREA
         LR    R13,R1                    OK -- SAVE AREA ALL SET UP

Quote:
>All other registers [besides 0, 1, 2, 13, 14 and 15]
>can be used for base or scratch as you like.
>Writing reentrant code (use RU-type GETMAIN for all data areas)
>is good practice but not much good otherwise.

Actually R2 is not used by any usual operating system functions, so
it's safe too (though the TRT instruction does use it as an implicit
operand).

Reentrant code is not that hard to do, and besides being good practice it
is critical if you ever use multiple tasks.  An easy way to arrange the
data areas is to make your save area (gotten above via GETMAIN) include
them after the register save area.  E. g.,

         USING R13,SAVEAREA

   ...

SAVEAREA DSECT
         DS    18F                      STANDARD OS SAVE AREA
<writable data areas go here>
SVLENGTH EQU   *-SAVEAREA               TOTAL LENGTH OF GETMAIN'ED AREA

You also need to learn about the MF=E forms of the MACROs -- what it
amounts to is that the standard forms of some MACROs don't generate
reentrant code because they have to create some kind of parameter list,
so they put it directly in the code and branch around it.  Those MACROs
all provide an MF=L form to generate the parameter list (as a constant)
and an MF=E form to fill it in and execute the operation.  You copy
the MF=L list into your work storage (again, in the GETMAIN'ed area)
and use MF=(E,<area>) to point to it.

Quote:
>...  Never write self-modifying code - there is
>always a better way to accomplish the same thing, generally with
>a table of things to pick up and EXECUTE with, if your program is
>so constituted.

Amen!

-----

(other points)

Note the use of symbolic names R<n> for the registers.  This helps because
it causes register references to appear in the cross-reference listing
generated by the assembler.  In a complex piece of code it can be
difficult to follow the register usage; having a listing can help this.

A related point:  pick a convention for your use of the registers,
document it in comments in the beginning of the routine, and STICK TO IT!
There is nothing more difficult than keeping track in one's mind of
the meaning of all the registers.  LOTS of bugs come from failing
to notice some subtlety in this area.

Finally, remember that no matter how well you write assembler code
it is almost always easier to write (and debug!) in a high-level language.
If what you are doing requires the use of assembler (e.g., because you need
to access some system interface that is only available from assembler),
a good approach is to write a small, well-defined subroutine in assembler
that can be called from a high-level language.



Mon, 16 Aug 1993 01:37:11 GMT  
 help for new assembly'er

Quote:
>On Wed, 27 Feb 91 04:32:34 GMT Laird J. Heal said:

>>All other registers [besides 0, 1, 2, 13, 14 and 15]
>>can be used for base or scratch as you like.
>>Writing reentrant code (use RU-type GETMAIN for all data areas)
>>is good practice but not much good otherwise.

>Actually R2 is not used by any usual operating system functions, so
>it's safe too (though the TRT instruction does use it as an implicit

I find its special status a good excuse to use it as a single scratch
register whose contents will not be normally modified by the operating
system.  There is no special error in using it, for example, as a base
register, but I can remember well solving a nightmare for a co-worker
by noting that the last byte of R2 was providing him with a little
unexpected auto-indexing.

Quote:
>>Since registers zero, one and two can be modified by everything from
>>SVCs to TRTs, use them for scratch areas.  R15 is your entry address
>>but you should save it off - R12 is typically used for this and thus
>>as the code base register.  R14 is the return address but can be used
>>within your code as can R15, as the OS never really relies on them.
>>R13, on the other hand, should always point to your Register Save
>>Area, unless you are working with DOS/VSE/POWER, in which case I
>>commend your soul to the appropriate power.
>Please note that at least in OS/MVT and VS/1 and (presumably) the
>various MVS variants, and the OS Simulation routines under VM/CMS,
>that the various QSAM I/O macros (such as GET and PUT), involve
>a  BALR  14,15  - so these registers should *not* be used except as
>scratch unless you *know* that any system macros you use don't modify
>these registers.  Incidentally, macros like this are the *REASON* you
>usually use R12 as the base rather than R15....

Excuses for the extensive attributions.  You note that I was commenting
on scratch registers.  Simply put, I was cautioning against using R13
for anything except save area chaining.  The other registers (from R14
to R2) are not so sacrosanct.  Some folks use R2 for a base register or
such - I feel this is a mistake of style, but since TRT is not normally
used, it often is harmless.

During my first class in BAL, the assistant (who was grading all of the
exercises) said "always use PRINT GEN" to which the instructor said
"you mean, never use PRINT GEN".  I tend to the "always" mode.
--
Laird J. Heal                           The Usenet is dead!



Thu, 19 Aug 1993 18:30:02 GMT  
 help for new assembly'er


Quote:
>On Wed, 27 Feb 91 04:32:34 GMT Laird J. Heal said:

>>All other registers [besides 0, 1, 2, 13, 14 and 15]
>>can be used for base or scratch as you like.
>>Writing reentrant code (use RU-type GETMAIN for all data areas)
>>is good practice but not much good otherwise.

>Actually R2 is not used by any usual operating system functions, so
>it's safe too (though the TRT instruction does use it as an implicit

I find its special status a good excuse to use it as a single scratch
register whose contents will not be normally modified by the operating
system.  There is no special error in using it, for example, as a base
register, but I can remember well solving a nightmare for a co-worker
by noting that the last byte of R2 was providing him with a little
unexpected auto-indexing.

Quote:
>>Since registers zero, one and two can be modified by everything from
>>SVCs to TRTs, use them for scratch areas.  R15 is your entry address
>>but you should save it off - R12 is typically used for this and thus
>>as the code base register.  R14 is the return address but can be used
>>within your code as can R15, as the OS never really relies on them.
>>R13, on the other hand, should always point to your Register Save
>>Area, unless you are working with DOS/VSE/POWER, in which case I
>>commend your soul to the appropriate power.
>Please note that at least in OS/MVT and VS/1 and (presumably) the
>various MVS variants, and the OS Simulation routines under VM/CMS,
>that the various QSAM I/O macros (such as GET and PUT), involve
>a  BALR  14,15  - so these registers should *not* be used except as
>scratch unless you *know* that any system macros you use don't modify
>these registers.  Incidentally, macros like this are the *REASON* you
>usually use R12 as the base rather than R15....

Excuses for the extensive attributions.  You note that I was commenting
on scratch registers.  Simply put, I was cautioning against using R13
for anything except save area chaining.  The other registers (from R14
to R2) are not so sacrosanct.  Some folks use R2 for a base register or
such - I feel this is a mistake of style, but since TRT is not normally
used, it often is harmless.

During my first class in BAL, the assistant (who was grading all of the
exercises) said "always use PRINT GEN" to which the instructor said
"you mean, never use PRINT GEN".  I tend to the "always" mode.
--
Laird J. Heal                           The Usenet is dead!



Thu, 19 Aug 1993 18:30:02 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. help for new assembly'er

2. Document'er and Diagram'er ???

3. A few idioms and programs for new J'ers

4. New REXX'er

5. The Tcl'ers Wiki - new URL

6. help for new Prolog-er

7. sed'ers & awk'ers part II - help!

8. If you're a TPF'er check out the Alternative TPF Homepage

9. determining name of 'send'er

10. Yet more new work for PL/I-ers....

11. New Assembly Programmer needs help of Expert.

12. a puzzle for j'ers

 

 
Powered by phpBB® Forum Software