Metal C does permit ARCH and TUNE overrides, and it is *hugely* instructive to look at the differences in the generated HLASM code as you move up the ARCH scale from 5 to 8, especially with OPTIMIZE(3). Difficult to follow, but highly instructive.
It is true that Metal C will not permit you to specify anything LESS than ARCH(5). Metal C also permits HGPR and CSECT to be overridden. I haven't played with floating point in Metal C yet, so I am not sure about the FLOAT option, and I have not used the z/Unix debugger at all so I do not know if the DEBUG options can be overridden. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: Friday, April 13, 2012 12:24 PM To: [email protected] Subject: Re: Modernizing the BCP code ? On 13 April 2012 10:23, Kirk Wolf <[email protected]> wrote: > It is also interesting (to me) to point out that "Metal C" uses the same > back-end. One would think so, but I'm not so sure... > Metal-C generates assembler code which is not dependent on the C library or > LE, supports user inlined assembler code, etc. Just like with C/C++, you > can specify ARCH(),TUNE(), INLINE, etc. Well actually, no, unless they've fixed it recently. The doc says you can, but if you specify e.g. ARCH(0), along with METAL, you will get a complaint: CCN0790(S) Options "METAL" and "ARCHITECTURE(0)" are in conflict. What the book says is that: METAL disables: DLL RENT XPLINK IPA HOT DFP METAL sets the following as defaults: ARCH(5) TUNE(5) CSECT HGPR(PRESERVE) FLOAT(IEEE) NOLONGNAME NODEBUG(FORMAT(DWARF),NOHOOK,SYMBOL) METAL ignores the following: TARGET INLRPT GOFF INLINE when OPTIMIZE(0) is in effect All suboptions of INLINE When it says "sets the following as defaults", I assumed they could be overridden, but it seems not. Perhaps it should say "METAL forces the following"... Or maybe it's almost right, and it's only downlevel code generation they don't do. I haven't played with other combinations of the "sets the following as defaults" group. > With the explosion of new instructions, at what point does writing > hand-written assembler code become less and less practical? The old instructions continue to work perfectly well, and it's easy to take advantage of new instructions that are primarily functional rather than performance oriented, for instance the decimal FP set, the 20-bit displacement ones, unsigned arithmetic, the various rotates, and so on and so on. But it may be that when writing high performance assembler routines it is now a lot harder to win a battle with a compiler that has advanced knowledge of the underlying machine internals. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
