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
