Chris Craddock wrote:
> The rest was just making sure it did what I wanted and for that, I
used Dave Cole's c/XDC.
> As usual, I can't say enough good things about Cole Software.
Thanks for the shout out, Chris. Always Appreciated.
Dave
[email protected] (personal)
[email protected] (business)
540-456-6518 (cell)
At 7/20/2023 10:57 AM, Chris Craddock wrote:
Hi Phil,
wrt: "We hit limitations with the macro preprocessor pretty often,
in part because our code is multi-platform, so we have lots of
multipathing for which #if and friends just don't suffice. I'll
admit that it probably doesn't help that I'm an assembler guy and
thus immediately think "Gee, this would be trivial with an assembler macro"."
I too am "an assembler guy", but I was writing C in the late 70's,
long before I wrote my first 370 asm program. I wrote the new
product on my Mac so I could use a good IDE - JetBrains CLion. This
forced me to use some boilerplate like this ...
#define plist_id 0x40e3d7d3 // " TPL"
// calling Assembly programs from C++ is a PITA in IBM's C++. The code
// below expands correctly on the mainframe and the IDE doesn't whine
#ifdef __IBMCPP__
#pragma map(doAuthCall,"TAAGOAPF")
extern "OS" { int doAuthCall(parm_array *); }
#else
extern "C" { int doAuthCall(parm_array *); }
#endif
but really not that much. I really did not need or use much of the
C/C++ macro preprocessor. Wherever I needed to use assembler, the
C++ code would just call the assembler program, which had LE entry
and exit macros. From there I could do anything I needed (issue PC calls etc.)
As the comment implies, this allowed the IDE to properly validate
data types, parameter lists etc. and, quite frankly, it was a life
saver. I knew before I even compiled the code on z/OS that it was
syntactically valid. The rest was just making sure it did what I
wanted and for that, I used Dave Cole's c/XDC. As usual, I can't say
enough good things about Cole Software.
If I was doing more z systems software development, I would be
sorely tempted to reuse this approach. Worked like a charm.
CC
________________________________
From: IBM Mainframe Assembler List
<[email protected]> on behalf of Phil Smith III
<[email protected]>
Sent: Wednesday, July 19, 2023 4:38 PM
To: [email protected] <[email protected]>
Subject: Re: looking for limbo languages - how low can you go?
Chris Craddock wrote, in part, re:
>>"It's silly to say that C hardware near. I would say less than
5% of the x86 or z instructions are used by the language."
>You would be shocked if you looked at a z/OS C++ listing. Spoiler: the
>C/C++ compiler and libraries exploit the living shit out of the z
>architecture instruction set. There are waaaay more new instructions
>in the generated C++ than in the HLASM part (I wrote both parts).
Indeed! And the generated code between opt(0) and opt(3) is so
different, it's hard to believe it's doing the same thing, yet it
is. It's impressive as hell. In the one compute-intensive case that
we measured, unoptimized used half again as much CPU.
>It is true that the C/C++ macro processor is pretty dumb compared to
>the HLASM macro language. And yet that doesn't seem to be much of a
>limitation if any. The programming models are just different.
Well.like all good questions, "it depends". We hit limitations with
the macro preprocessor pretty often, in part because our code is
multi-platform, so we have lots of multipathing for which #if and
friends just don't suffice. I'll admit that it probably doesn't
help that I'm an assembler guy and thus immediately think "Gee,
this would be trivial with an assembler macro". Sometimes there are
ways to do it with the macro preprocessor; sometimes I'm told "You
just can't do that". And in those cases, I'm assuming that the
folks telling me that know what they're on about. Which, of course,
might be wrong!
...phsiii
