Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

ASM Code Generated by the COBOL Compiler

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message
bengtpelle

New User


Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL

PostPosted: Wed Jun 03, 2009 11:13 pm    Post subject:
Reply with quote

You should be aware of the tremendeous number of variations of code that will be generated by cobol for a single instructions such as ADD A TO B.
Here are a few variations of the PICTURE statement that will cause totaly different code to be generated.

DISPLAY
COMPUTATIONAL
COMPUTATIONAL-x
Size of field
Even or odd number of characters in field
If the field is Signed or not
Number of Decimals
Indexed field

All of above and some more can if I remember correctly generate about 200 variations of code for the simple ADD, SUB, MOVE, MULT and so on.

The most expensive once when it comes to code generated are:
DISPLAY
Unsigned field
Even number of digits
Indexes with a picture of Display can generate 10 times more code in a program.

I know since I was part of the IBM development team for the COBOL compiler.
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Jun 04, 2009 12:01 am    Post subject: Reply to: Assembler language insructions
Reply with quote

Doubleword-Binary fields which require (when needed) a BALR to a COBOL run-time module to perform some types of arithmetic, can also be very expensive.

I have a question for you. Why does COBOL generate an MVCL when using variables (lengths) as part of reference modification, instead of interrogating the given length and determine whether it's a candidate for an EX over an MVC, if the length does not exceed 256?

PL/I determines the length and issues an EX over an MVC when the length is not greater than 256.

Just curious....

Regards,
Back to top
View user's profile Send private message
bengtpelle

New User


Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL

PostPosted: Thu Jun 04, 2009 3:38 am    Post subject:
Reply with quote

The length of the move is a run time issue and not a design time issue. If I remember right, the MVCL is used to handle any size field. Executing an MVC could be dangerous if a field is modified to be more then 256 bytes. I guess that was the reasoning behind it.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Jun 04, 2009 6:32 am    Post subject: Reply to: ASM Code Generated by the COBOL Compiler
Reply with quote

I understand the 256-byte limitation on the MVC instruction. But, how can the PL/I folks recognize the dynamic-length and the compiler generates an EX over an MVC?

An MVCL is an interruptible instruction, requiring four registers for usage, but for the COBOL compiler to issue this instruction, specifying (for example) a receiving and sending register value set to an F'1', seems like a waste of cycles.

Just my .02 cents....
Back to top
View user's profile Send private message
bengtpelle

New User


Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL

PostPosted: Thu Jun 04, 2009 6:36 pm    Post subject:
Reply with quote

I do not know how PL/1 determines it. Probably the definition of the fields are used to determine what to generate. The original COBOL compiler did not use the MVCL since it did not exist in the first computers (360). Somehow it must have been changed in later versions and I do not know why.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10231
Location: italy

PostPosted: Thu Jun 04, 2009 6:44 pm    Post subject: Reply to: ASM Code Generated by the COBOL Compiler
Reply with quote

simply because the pl1 compiler is a bit smarter than the cobol compiler icon_biggrin.gif

the same way it determines that it has to build a sequence of mvc' s for 256 bytes, followed by a last mvs for the residual part

for static moves the length available at compile time and the decision can be taken there

for dynamic moves the process is similar

a loop of mvc' s for a 256 bytes length
followed by an executed mvc for the residual

as far as the mvcl is concerned, a religion war might come out icon_biggrin.gif
Back to top
View user's profile Send private message
bengtpelle

New User


Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL

PostPosted: Thu Jun 04, 2009 7:40 pm    Post subject:
Reply with quote

I fully agree.
In the so called IOCS the IO-Modules for E.G. Variable length records uses the loop over an MVC followed by an executed move for the residual when it has to move a record to a work area.
This is by far the best method.
Using four registers for a transaction is a total waste.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts JCL to Set Return code based on DB2 S... vinu78 DB2 17 Mon Mar 13, 2017 9:47 pm
No new posts IMS region inactive - User abend code... gthmrj IMS DB/DC 5 Tue Mar 07, 2017 12:29 pm
No new posts CA Workload Automation event code help vinu78 CA Products 10 Wed Mar 01, 2017 10:05 am
No new posts SQL query not working in Cobol program. CuriousMainframer COBOL Programming 14 Wed Feb 22, 2017 5:56 pm
No new posts Execute TSO ACF commands from COBOL-I... supreethi.srid TSO/ISPF 0 Tue Feb 21, 2017 5:19 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us