how to deal with pseudo-code by the computer?



High Level Assembler(HLASM) for MVS & VM & VSE

how to deal with pseudo-code by the computer?

Postby bobguo » Sat Mar 23, 2013 5:11 am

Hi guys,
i have one question which puzzled me for a long time.

 0013C8 58E0 5230            00230  3649          L     R14,SAVECWA   
                  R:E  00000        3650          USING DFHCWADS,R14   
 0013CC D703 E2C0 E2C0 002C0 002C0  3651          XC    CWADASH,CWADASH 
                                    3652          DROP  R14           


As the above code shows, both USING and DROP don't generate objective code, so when these code were executed, how does the computer know USING and DROP's purpose? In other words, where does this information(USING/DROP) store? how to deal with it by the computer?


Sincerely,
Bob
bobguo
 
Posts: 76
Joined: Thu Apr 26, 2012 11:18 am
Location: shanghai
Has thanked: 22 times
Been thanked: 0 time

Re: how to deal with pseudo-code by the computer?

 

Re: how to deal with pseudo-code by the computer?

Postby steve-myers » Sat Mar 23, 2013 5:34 am

bobguo wrote:Hi guys,
i have one question which puzzled me for a long time.

 0013C8 58E0 5230            00230  3649          L     R14,SAVECWA   
                  R:E  00000        3650          USING DFHCWADS,R14   
 0013CC D703 E2C0 E2C0 002C0 002C0  3651          XC    CWADASH,CWADASH 
                                    3652          DROP  R14           


As the above code shows, both USING and DROP don't generate objective code, so when these code were executed, how does the computer know USING and DROP's purpose? In other words, where does this information(USING/DROP) store? how to deal with it by the computer?


Sincerely,
Bob
USING and DROP are "assembler instructions." They are not machine instructions; an Assembler instruction just tells the Assembler to do something, but the computer system never sees them. USING, as shown here, just tells the Assembler which registers are to be used as a base register and what value you have promised to put in the base register. DROP just deletes the register from the base registers.
steve-myers
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: how to deal with pseudo-code by the computer?

Postby steve-myers » Sat Mar 23, 2013 5:45 am

USING and DROP are a convenience for the programmer. Which do you prefer?

XC CWADASH,CWADASH
or
XC CWADASH-DFHCWADS(,14),CWADASH-DFHCWADS(14)
steve-myers
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: how to deal with pseudo-code by the computer?

Postby bobguo » Sat Mar 23, 2013 6:02 am

"just tells the Assembler which registers are to be used as a base register and what value you have promised to put in the base register"

As you said, these instructions how to tell Assembler these information concretely? or can i guess is there one label in someplace of the memory to be set to indicate which registers are to be used as a base register...?
bobguo
 
Posts: 76
Joined: Thu Apr 26, 2012 11:18 am
Location: shanghai
Has thanked: 22 times
Been thanked: 0 time

Re: how to deal with pseudo-code by the computer?

Postby bobguo » Sat Mar 23, 2013 6:22 am

and i think DSECT is similar with it.

DSECT also doesn't occupy any memory, after it was assembled, it generates nothing? If so, all the information DSECT wants to say, the computer how to knows when the program was running?
bobguo
 
Posts: 76
Joined: Thu Apr 26, 2012 11:18 am
Location: shanghai
Has thanked: 22 times
Been thanked: 0 time

Re: how to deal with pseudo-code by the computer?

Postby Robert Sample » Sat Mar 23, 2013 6:28 am

If you look at the left side of the code you posted, you will see the machine instructions. 58E0 5230 is how the load translated -- and this means that you are using register 5 for your base register and SAVECWA is at offset hex '0230' from the address loaded in register 5. D703 E2C0 E2C0 is how the XC translated, and E2C0 means CWADASH occurs at offset hex '02C0' from the start of SAVECWA, while E is the base register being used. Note that the base register will depend upon the data you are accessing, and more than one base register may be used in the same instruction. When you assemble the program, the assembler keeps track of the base register (or registers) as part of the assembly process. While there's most likely some place in the assembler where this data is stored, unless you go to work for IBM and work in the assembler development / support section, you are not likely to ever find out much detail about the process. You should start reading the IBM Principles of Operation (POP) manual. You can find it at http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 222 times

Re: how to deal with pseudo-code by the computer?

Postby steve-myers » Sat Mar 23, 2013 7:32 am

bobguo wrote:... or can i guess is there one label in someplace of the memory to be set to indicate which registers are to be used as a base register...?
There is no such idea in the hardware. That idea might be OK for your address space, but how about shared storage like the nucleus (CVT, for example) or CSA, where one section of storage might be used by many programs?
steve-myers
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: how to deal with pseudo-code by the computer?

Postby steve-myers » Sat Mar 23, 2013 8:09 am

bobguo wrote:and i think DSECT is similar with it.

DSECT also doesn't occupy any memory, after it was assembled, it generates nothing? If so, all the information DSECT wants to say, the computer how to knows when the program was running?
  • "DSECT also doesn't occupy any memory" Both true and not true. A DSECT is a picture of what memory, somewhere, looks like. A DCB for example, often is part of your program and occupies memory. The DCBD macro generates a lot of Assembler instructions that are in the IHADCB DSECT. The DSECT occupies no storage as you say, but when you use the IHADCB DSECT to look at or modify (if you know what you're doing) the real DCB in your program it is definitely using storage. Many times I do something like this in my programs.

    MVC DCBDDNAM-IHADCB+MYDCB,somewhere

    MYDCB DCB ...,DDNAME=FILLMEIN

    DCBD DSORG=QS,DEVD=DA

    Another way to do the first line might be

    LA areg,MYDCB
    USING IHADCB,myreg
    MVC DCBDDNAM,somewhere
    DROP areg
  • "it generates nothing" A DSECT usually contains many DS Assembler instructions that are the picture of storage. A DSECT does not initialize storage.
  • "the computer how to knows when the program was running" The computer knows how to execute machine instructions that are part of your program. That is all the computer "knows." Used properly, a DSECT assists the Assembler to generate the machine instructions that perform the task your program is to achieve.
steve-myers
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times


Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post