[Comments below]
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Kirk Wolf
> Sent: Tuesday, April 05, 2011 4:17 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: CPU: ASSM vs ENTERPRISE COBOL
>
> I'm not really disagreeing with any of the comments on this
> interesting thread; My $.02 -
>
> - The influence of good application architecture, design, and
> implementation is nearly always more important than the choice of
> language.
Agreed, 100%.
> - Good developers usually pick the right tools for the job.
> Assembler, C/C++, Java, PL/x, COBOL, and REXX are all great languages
> on z/OS when used correctly.
Unless constrained by politics.
> As pointed out earlier on this thread, the choice between using
> Assembler and a HLL for performance-critical code is a little
> complicated. I'm a decent assembler programmer, but I'm completely
> intimidated by the code generated by the IBM C/C++/Metal-C and Java
> JIT compilers. As Metal-C offers the ability to mix assembler and HLL
> together I find less and less need to write pure Assembler.
>
> Consider this function, which Metal-C will happily inline into calling
> code:
>
> static char const itoa_mask[13] =
> {'-',0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x21,0x20,'\0'};
> static char* itoa10(int i, char* buf13) {
> unsigned char packed[8] __attribute__((_aligned__(8)));
> unsigned char* pSigdigit = buf13 + sizeof(itoa_mask)-2;
> memcpy(buf13, itoa_mask, sizeof(itoa_mask));
> __cvd (i, packed);
> __edmk( buf13,
> packed+2,
> sizeof(itoa_mask)-2,
> &pSigdigit);
> return (i < 0) ? pSigdigit-1 : pSigdigit;
> }
>
> Sure, an assembler macro would generate the same handful of
> instructions inline as Metal-C, but would the assembler then rearrange
> the instructions to optimize pipeline and cache-hits? (using techniqes
> that I don't even understand :-) Does IBM even publish the
> information necessary to really optimize code for the current
> instruction set?
>
> Maybe there would be a market for a code optimizer that would process
> the ADATA output from HLASM (or even existing load module text) and
> apply optimizations to it? Maybe it could even dissect code into
> pieces for enclave-mode SRBs :-)
<Snipped>
IMHO, better would be for the COBOL compiler team to give up their proprietary
optimizer and code generator and become a front-end for the C/C++ optimizer and
code generator, just like GNU Pascal and GNU Fortran are front-ends to the GCC
optimizer and code generator phases.
I too have seen a little of the awesome code that Metal-C generates with
ARCH(8) TUN(8) OPT(3), and I am very, very impressed.
I think you're really dreaming though about the enclave-mode SRB stuff. I
think that's got two chances, Slim and None, and Slim's out to lunch.
> PS> If Metal-C were extended to (somehow) directly support existing
> bi-modal BAL-PL/x macros, there would be very little need for us to
> write assembler. This would be the single biggest thing that IBM
> could do IMO to foster application development on z/OS.
I have to say that recent incarnations of the utility EDCDSECT do quite a
creditable job of translating HLASM control block structures. With the
exception of just generating a tagged structure instead of a typedef, I have
had few complaints. And the typedef issue is easily solved with a Rexx
post-processor.
OTOH the EDCDSECT utility does not, of course, handle the PL/x structure
definitions, just the assembler ones, and nothing handles the macros that
actually do something as opposed to describing something.
Peter
--
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.
