Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist 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: 2504
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: 2504
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: 10457
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 Linkage editor is part of COBOL, z/OS... ankit.jain COBOL Programming 4 Fri Apr 20, 2018 4:17 pm
This topic is locked: you cannot edit posts or make replies. Difference between EQUAL and EQUAL TO... jithinraghavan COBOL Programming 3 Thu Apr 19, 2018 2:22 am
No new posts Call COBOL or PLI with a click from w... vaibhav gs All Other Mainframe Topics 1 Mon Apr 16, 2018 7:29 pm
No new posts Getting GG return code abdulrafi IMS DB/DC 2 Tue Apr 10, 2018 12:31 pm
No new posts COBOL MVS options BiswajitDG COBOL Programming 8 Fri Apr 06, 2018 12:35 am

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us