|
View previous topic :: View next topic
|
| Author |
Message |
bengtpelle
New User
Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL
|
|
|
|
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 |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
bengtpelle
New User
Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL
|
|
|
|
| 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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
bengtpelle
New User
Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL
|
|
|
|
| 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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
simply because the pl1 compiler is a bit smarter than the cobol compiler 
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 |
|
| Back to top |
|
|
bengtpelle
New User
Joined: 28 Aug 2006
Posts: 24
Location: St. Petersburg, FL
|
|
|
|
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 |
|
|
|
|
