Page 3 of 5

Re: Trouble with assembler subroutines

PostPosted: Wed Nov 23, 2011 12:11 pm
by dick scherrer
Hello,

There's something interesting. How do you walk on memory?
Not ensuring the code is using only locations within the process.

Re: Trouble with assembler subroutines

PostPosted: Wed Nov 23, 2011 5:24 pm
by Robert Sample
If my post implied all the code problems were listed, I'm sorry -- I certianly did not mean that . I looked at the code until I found the first thing that could cause a "crash" (ABEND for professionals) and stopped looking at that point. Based on the first few lines, I'm certain there are plenty of other problems!

The classic method of walking on memory is to define a table with a fixed number of elements, say 10. You then store values in that table past the upper limit -- everything you store after the 10th element (if the limit is 10) will be stored in memory, but not the memory of the table. Do this long enough in many programs, and you'll corrupt the program instructions.

Re: Trouble with assembler subroutines

PostPosted: Wed Nov 23, 2011 10:31 pm
by RISCCISCInstSet
Partway revised:

LAB6A    SUBENTRY
LAB6A    CSECT
       
         BALR    12,0
         USING   *,12
         SAVE    (14,12)
         BALR    12,0
         USING   *,12
         LA      2,SAVEAREA
         ST      2,8(,13)
         ST      13,4(,2)
         LR      13,2
         LA      1,DATA
         
         
         
         BAL    15,SUMRTN
         BAL    15,SUMRTN
         BAL    15,SUMRTN
         LA     3,X'00000000'
         LA     4,X'00000001'
         LA     5,X'00000063'
         ZAP   B,=P'0'
         ZAP   SUM,=P'0'
         ZAP   A,=P'1'

LOOP     DS    0H
         AP    B,A
         AP    SUM,B

         BXLE  3,4,LOOP
         
         MVC  FIELD,MASK
         ED   FIELD,SUM
         WTO  MF=(E,WTOMSG)
         SUBEXIT

WTOMSG   DC AL2(WTOMEND-*,0)
HELLO    DC  C'THE SUM OF THE NUMBERS FROM 1 TO 100 IS '
FIELD    DS CL10
WTOMEND  EQU *

*
MASK     DC X'40206B2020206B202020'
PRNTLINE DS CL133
SUM      DS PL4
B        DS PL4
A        DS PL4
C        DS PL4
CB       DS PL4
DB       DS PL4
SAVEAREA DS 18F
DATA     DC CL5'00800'
SUMRTN   DS      0H
         WTO 'NONSENSE'
         BR      15

ENDPGM   DS  D

    END  LAB6A

Re: Trouble with assembler subroutines

PostPosted: Wed Nov 23, 2011 11:20 pm
by enrico-sorichetti
Your partway was the wrongway anyway :ugeek:

as already somebody told You ...
the register save should precede the setting up of the base register

and as usual You did not care to read the z390 documentation,
You just copied thing without trying to understand

the subentry and the subexit macros ...

.*             MACRO-ID. 'SUBENTRY'                                     
.*             AUTHOR.   DON HIGGINS.                                   
.*             DATE WRITTEN.  07/28/70.                                 
.*             REMARKS.  THIS MACRO GENERATES THE CODE TO ESTABLISH A   
.*                       CSECT WITH SAVE AREA AND BASE REGISTER USING   
.*                       STANDARD OS LINKAGE CONVENTIONS.       


so no reason at all to redo what has already been done ( saving the registers and <loading> the base register )

and ... did You notice that the SUMRTN was entered once, but
as usual if You had read the documentation and followed the run time instructions

See errors in lab6a.log


You would have noticed that both in the console log and in lab6a.log the register 15 contains a nice 0, hence the 0c1

repeat novemtrigillion times

any subroutine using zOS macros must abide the CALL conventions and save/restore properly the registers

when You will have gained more experience You might be stingy to save and restore only the register being used
like I did in the quick and dirty mod I made
but to start with, just follow the normal/best practice of saving and restoring everything

after fixing the obvious I got the correct results

18:41:14 lab6a     EZ390 START USING z390 V1.5.05 ON J2SE 1.6.0_29 11/23/11
NONSENSE FROM SUMRTN
NONSENSE FROM SUMRTN
NONSENSE FROM SUMRTN
THE SUM OF THE NUMBERS FROM 1 TO 100 IS      5,050
18:41:14 lab6a     EZ390 ENDED   RC= 0 SEC= 0 MEM(MB)= 14 IO=24 INS=340


I just made the simple hack of defining a save area for R15
here is the <fixed> thing

LAB6A    SUBENTRY
         LA      1,DATA
         BAL    15,SUMRTN
         BAL    15,SUMRTN
         BAL    15,SUMRTN
         LA     3,X'00000000'
         LA     4,X'00000001'
         LA     5,X'00000063'
         ZAP   B,=P'0'
         ZAP   SUM,=P'0'
         ZAP   A,=P'1'

LOOP     DS    0H
         AP    B,A
         AP    SUM,B
         BXLE  3,4,LOOP
         MVC  FIELD,MASK
         ED   FIELD,SUM
         WTO  MF=(E,WTOMSG)
         SUBEXIT

WTOMSG   DC AL2(WTOMEND-*,0)
HELLO    DC  C'THE SUM OF THE NUMBERS FROM 1 TO 100 IS '
FIELD    DS CL10
WTOMEND  EQU *

*
MASK     DC X'40206B2020206B202020'
PRNTLINE DS CL133
SUM      DS PL4
B        DS PL4
A        DS PL4
C        DS PL4
CB       DS PL4
DB       DS PL4
SAVEAREA DS 18F
SAV15    DS F
DATA     DC CL5'00800'


SUMRTN   DS      0H
         ST      15,sav15
         WTO 'NONSENSE FROM SUMRTN'
         L      15,sav15
         BR      15

ENDPGM   DS  D

    END  LAB6A


now it it the time to stop wasting time creating what You properly define stupid gibberish ;)
and start rereading all the post You have made, trying to understand the answers You were given !

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 6:19 am
by RISCCISCInstSet
enrico-sorichetti wrote:Your partway was the wrongway anyway :ugeek:
Yeah I misunderstood what the presentation pdf I was using was trying to say. I most likely should have tried harder to RTFM. Anyway, that's helpful, and I'll get back to you if I still have an issue understanding subroutines. After examining (technical) documentation.

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 8:40 am
by steve-myers
That's pretty good! I'd make these changes:
         SR    3,3
         LA    4,1
         LA    5,99
No sense putting in mystery hexadecimal values! There is nothing wrong with LA 3,0. In fact since the LA instruction does not alter the condition code and SR does alter the condition code it might be preferred.
FIELD    DC    C' N,NNN,NNN'
I prefer to self document. A DS instead of a DC is OK, too, but I generally prefer to initialize storage with something, which, at least in theory, a DS does not do.
MASK     DC   0C' N,NNN,NNN',C' ',X'20',C','
         DC    X'202020',C',',X'202120'
Here, again I self document and also void mystery hexadecimal vales. Note, too, the use of a significance start code in the last 3 digit group. In real code I'd put all of this on one line, probably continued to a second line, but I can't do this here because of the limited width of a code block.

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 9:30 am
by RISCCISCInstSet
@steve-myers Thanks

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 10:24 am
by RISCCISCInstSet
Okay - I don't want to act like a cheater so - BAL 15,SUMRTN (branch and link) sends you off to the subroutine (SUMRTN), saving the address of the next instruction in register 15. in the subroutine, register 15 is stored in SAV15, the message is run, then SAV15 is loaded in the register. Some field testing shows SAV15 was used to prevent the message from disrupting what was in register 15, probably because of the nature of the subroutine.

So anyway I'd be happy to read about why that happened to register 15. Surely something to do with the Subentry and Subexit macros. If you'd prefer I read documentation I wouldn't be offended.

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 11:24 am
by RISCCISCInstSet
Stupid subroutines, they're not like higher level functions/methods... Oh well, my bad for expecting assembler to act like compiled code. An update is below:
LOOP     DS    0H
         BAL   15,SUMRTN
         BXLE  3,4,LOOP
...
SUMRTN   DS    0H
         ST    15,sav15
         AP    B,A
         AP    SUM,B
         L     15,sav15
         BR    15

Re: Trouble with assembler subroutines

PostPosted: Thu Nov 24, 2011 1:20 pm
by enrico-sorichetti
So anyway I'd be happy to read about why that happened to register 15. Surely something to do with the Subentry and Subexit macros. If you'd prefer I read documentation I wouldn't be offended.


the subentry and subexit have nothing to do with it ..

R15 is <clobbered> from what happens inside the SUMRTN ...
but that would have been clear if instead of just <copying> a WTO You had taken the time to read the relevant manuals

z/OS V1R10.0 MVS Programming Assembler Services Guide
http://publibz.boulder.ibm.com/cgi-bin/ ... 0523015946
z/OS V1R10.0 MVS Programming Assembler Services Reference Vol 1 (ABEND-HSPSERV)
http://publibz.boulder.ibm.com/cgi-bin/ ... 0522045539
z/OS V1R10.0 MVS Programming Assembler Services Reference Vol 2 (IARR2V-XCTLX)
http://publibz.boulder.ibm.com/cgi-bin/ ... 0601235844

where for each macro is described in detail and You would have noticed - if <You had read it>
the sections
88.1.4 Input Register Information
( irrelevant in this case )
and
88.1.5 Output Register Information


When control returns to the caller, the output registers contain the following values:

Register Contents

0
Used as a work register by the system unless WTO returns code X'20' in register 15. In that case, register 0 contains the number of active WTO buffers for the issuer's address space.
1
Message identification number if the WTO macro completed normally (you can use this number to delete the message when it is no longer needed); otherwise, used as a work register by the system.

2-13
Unchanged.
14
Used as a work register by the system.
15

Return code.
When control returns to the caller, the access registers (ARs) contain:

Register Contents

0-1
Used as work registers by the system

2-13
Unchanged
14-15
Used as work registers by the system

Some callers depend on register contents remaining the same before and after issuing a service. If the system changes the contents of registers on which the caller depends, the caller must save them before issuing the service, and restore them after the system returns control.


so the registers modified by the WTO are 0,1,14,15
that' s the reason I said that the SAV15 hack was a quick and dirty one ...
I DID not want to read the whole program to find the register usage and fixed only the R15 clobbering.

again and again READ THE FRIENDLY MANUALS , if You had done that from the beginning You would have asked many less questions !