I personally wouldn't use Metal-C for writing exits. Unless they are
very simple structures the DSECT conversion utility is painful due to
the ambiguous syntax of assembler data declarations. It takes a "best"
guess, which sometimes works and sometimes makes a horrible mess.
If IBM provided C structure equivilent's for SYS1.MACLIB/MODGEN etc it
would make a big difference. But that's not going to happen anytime soon!
The interesting thing about Metal-C is that the runtime is shipped as
part of the base operating system. So even if you don't have a C license
there's lots of good stuff in there.
For example, a fancy heap memory allocator which could easily be used by
assembler programmers just by figuring out the linkage. Cell pools are
good but malloc()/free() have
any extra layer of abstraction on top.
I've noticed that on ARCH(8) (Z114-z196) machines the C/C++ compiler
optimizer can insert prefetch instructions into the code to keep the
pipeline from stalling due to a cache misses.
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.cbcux01/prefetch.htm
Chris Donawa posted a good blog (with profiling) showing how to
explicitly use the prefect instruction built-in. Nearly 50% net gain in
performance.
https://www.ibm.com/developerworks/mydeveloperworks/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/exploiting_the_z10_prefetch_built_in25?lang=en
On 13/04/2012 10:23 PM, Kirk Wolf wrote:
It is also interesting (to me) to point out that "Metal C" uses the same
back-end.
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.
With the explosion of new instructions, at what point does writing
hand-written assembler code become less and less practical?
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Thu, Apr 12, 2012 at 11:29 PM, Tom Ross<tmr...@stlvm20.vnet.ibm.com>wrote:
That is close to what I said. I said that C/C++ and PL/I currently share
a common back end, and that eventually IBM would like all compilers to
share
a common backend. In response to another comment, the JIT compiler does
create optimized sequences of instructions, and we hope to use some of
that technology as well in a new COBOL compiler release.
As for assembler code generated for COBOL usage of BINARY data items, we
are highly influenced by the COBOL standard. COBOL data items are all
base 10, with digits 1-9, so mapping BINARY data items to that requires
some trickery. The good news is that you can process dollars and cents
in many different data types with no floating points if you want to,
unlike some other languages.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
