Re: METAL C: CodeGen defeciency?
On Thu, 23 Apr 2009 11:55:18 -0500, Bill Klein wrote: >It looks as if Kelly posted this directly to the "newsgroup" and didn't send >it to the list. My apologies. Thanks Bill. Kel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Thu, 2009-04-23 at 12:55 -0400, Bill Klein wrote: > See "IBM response" "IBM response" in quotes, I know. Whatever influential IBMers are out there, know that at least one customer *really* appreciates this kind of give-and-take. ibm-main is not an official support forum, requirements should be taken up with SHARE or your business partner, yadda yadda. I understand all that. But I'm grateful for Peter, Jim, John, Greg, Tom, Marna, Martin, Martha, Kelly -- the list goes on. Y'all put the face on IBM. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Paul Gilmartin wrote: On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote: * setting 14 bytes to 0x00 XC102(14,13),102(13) You're only trying to help the programmer, but perhaps thereby thwarting the intent of a deliberate Dirty GETMAIN. This setting-of-zero is required by the ANSI C standard. Essentially, if you initialize part of an aggregate (in this case, an array) the remainder is given zero values. The array is defined as having 20 bytes, with only the first 6 being explicitly initialized by the programmer. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Let suppose IBM make processors with predicatble instruction speed, no heuristics etc , as it had been. We are back (with assembler) again ? Interesting that they didn't use XC, isn't it? If you spend any time looking at XLC generated code you will see lots of interesting stuff. Of particular interest is some of the loop unwinding optimizations. After a while you start to wonder if you should ever write in assembler again, since only IBM knows what instruction heuristics slide through the pipelines the best. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Wed, Apr 22, 2009 at 6:25 PM, Paul Gilmartin wrote:
> On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote:
>
>>Johnny Luo wrote:
>>> Hi,
>>>
>>> I was trying new METAL option of XL C and the following is the HLASM code
>>> generated :
>>>
>>> * {
>>> * char a[20]="12345";
>>> MVC 88(6,13),0(11)
>
> Is that the actual initialization, in which case the next 4
> instructions are incomprehensible?
>
>>> MVI @74a+6,0
>>> MVC @74a+7(13),@74a+6
>>> MVI @74a+6,0
>>> MVC @74a+7(13),@74a+6
>>> * return;
>>> * }
>>>
> I wouldn't expect it to move 13 characters to assign a 5-character
> (well, 6, counting the terminating NUL) in a 20-character buffer.
>
It is initializing the rest of the automatic storage to zeros (twice),
which probably has to do with the compiler options in effect.
I can't say why it is done twice; seems like a bug to me.
I would suggest that you compile the same thing with the regular XLC
compiler and look at the generated assembler listing to see if it does
the same thing (double zeroing).
Interesting that they didn't use XC, isn't it? If you spend any time
looking at XLC generated code you will see lots of interesting stuff.
Of particular interest is some of the loop unwinding optimizations.
After a while you start to wonder if you should ever write in
assembler again, since only IBM knows what instruction heuristics
slide through the pipelines the best.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote:
>Johnny Luo wrote:
>> Hi,
>>
>> I was trying new METAL option of XL C and the following is the HLASM code
>> generated :
>>
>> * {
>> *char a[20]="12345";
>> MVC 88(6,13),0(11)
Is that the actual initialization, in which case the next 4
instructions are incomprehensible?
>> MVI @74a+6,0
>> MVC @74a+7(13),@74a+6
>> MVI @74a+6,0
>> MVC @74a+7(13),@74a+6
>> * return;
>> * }
>>
I wouldn't expect it to move 13 characters to assign a 5-character
(well, 6, counting the terminating NUL) in a 20-character buffer.
>> It initialized the buffer twice! I cannot think of why. Is it normal?
>>
>>
>Not to point too many fingers, but since we did it first,
>here's what Systems/C did with Johnny's example:
>
>* *
>* *** char a[20]="12345";
> LA14,@lit_6_0
> MVC 96(6,13),0(14)
Wouldn't it work to:
MVC 96(6,13),@lit_6_0
...? If the LA works you have addressability. Yah, I know;
I've worked with (simple) code generators. I probably don't
understand the environmental constraints. Perhaps as simple
as the optimizer detected a need for R14 subsequently.
>* setting 14 bytes to 0x00
> XC102(14,13),102(13)
>
You're only trying to help the programmer, but perhaps thereby
thwarting the intent of a deliberate Dirty GETMAIN.
>* *** return;
>* *** }
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Johnny Luo wrote:
Hi,
I was trying new METAL option of XL C and the following is the HLASM code
generated :
* {
*char a[20]="12345";
MVC 88(6,13),0(11)
MVI @74a+6,0
MVC @74a+7(13),@74a+6
MVI @74a+6,0
MVC @74a+7(13),@74a+6
* return;
* }
It initialized the buffer twice! I cannot think of why. Is it normal?
Not to point too many fingers, but since we did it first,
here's what Systems/C did with Johnny's example:
* *
* *** char a[20]="12345";
LA14,@lit_6_0
MVC 96(6,13),0(14)
* setting 14 bytes to 0x00
XC102(14,13),102(13)
* *** return;
* *** }
- Dave Rivers -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
