Debugging METAL C
Edward Jaffe
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Sam Siegel
Edward Jaffe
> xdc
>
c/XDC or z/XDC?
Thomas David Rivers
> What do you use to debug your METAL C programs?
>
We use IBM's ASMIDF to debug the similar Dignus Systems/C
environment.
XDC would be a good choice too...
Systems/C provides DSECTs for automatic variables, and
has comments that include the original C code; so if you
have a nice ASM-level debugger that examines ADATA, you
can do some nice debugging at the assembler level.
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Sam Siegel
Edward Jaffe
> Edward Jaffe wrote:
>> What do you use to debug your METAL C programs?
>>
>
> We use IBM's ASMIDF to debug the similar Dignus Systems/C
> environment.
>
> XDC would be a good choice too...
>
> Systems/C provides DSECTs for automatic variables, and
> has comments that include the original C code; so if you
> have a nice ASM-level debugger that examines ADATA, you
> can do some nice debugging at the assembler level.
Unfortunately, METAL C's output is pretty awful looking, with little or
no referback to the original C source. That's why I was asking...
David Crayford
> Thomas David Rivers wrote:
>> Edward Jaffe wrote:
>>> What do you use to debug your METAL C programs?
>>>
>>
>> We use IBM's ASMIDF to debug the similar Dignus Systems/C
>> environment.
>>
>> XDC would be a good choice too...
>>
>> Systems/C provides DSECTs for automatic variables, and
>> has comments that include the original C code; so if you
>> have a nice ASM-level debugger that examines ADATA, you
>> can do some nice debugging at the assembler level.
>
> Unfortunately, METAL C's output is pretty awful looking, with little or
> no referback to the original C source. That's why I was asking...
>
I use z/XDC. I tried the XDC C debugger for LE C/C++ and was
disappointed. DebugTool has it's faults (and bugs) but has a better UI.
Especially the GUI in RDz. IMO, GUIs are a better UI for debuggers if
you have the screen real estate.
I have to disagree that METAL C assembler source lacks the neccessary
comments for debugging. Here's an example, which I think is fine...
* for (hash=0, i=0; i<len; ++i) 001270
USING @@PARMD@4,1 001270
ICM 0,B'1111',@313len@204 001270
LA 15,0 001270
LA 14,0 001270
BRE @4L265 001270
L 1,@312key@203 000000
@4L38 DS 0H 001270
* { 001271
* hash += key[i]; 001272
LLGC 2,0(14,1) (*)Cuchar 001272
ALR 15,2 001272
* hash += (hash << 10); 001273
SLLG 2,15,10 001273
ALR 15,2 001273
* hash ^= (hash >> 6); 001274
LR 2,15 001274
SRL 2,6 001274
XR 15,2 001274
AHI 14,1 001270
BRCT 0,@4L38 001270
* } 001275
* hash += (hash << 3); 001276
SLLG 14,15,3 001276
ALR 15,14 001276
* hash ^= (hash >> 11); 001277
LR 14,15 001277
SRL 14,11 001277
XR 15,14 001277
* hash += (hash << 15); 001278
SLLG 14,15,15 001278
ALR 15,14 001278
* return hash; 001279
* } 001280
Thomas David Rivers
> Thomas David Rivers wrote:
>
>> Edward Jaffe wrote:
>>
>>> What do you use to debug your METAL C programs?
>>>
>>
>> We use IBM's ASMIDF to debug the similar Dignus Systems/C
>> environment.
>>
>> XDC would be a good choice too...
>>
>> Systems/C provides DSECTs for automatic variables, and
>> has comments that include the original C code; so if you
>> have a nice ASM-level debugger that examines ADATA, you
>> can do some nice debugging at the assembler level.
>
>
> Unfortunately, METAL C's output is pretty awful looking, with little or
> no referback to the original C source. That's why I was asking...
>
Well - if you're going the "no/minimal runtime" route - you might want
to take a look at what Systems/C will do for you.
- Dave R. -
Thomas David Rivers
> Edward Jaffe wrote:
>
>> Thomas David Rivers wrote:
>>
>>> Edward Jaffe wrote:
>>>
>>>> What do you use to debug your METAL C programs?
>>>>
>>>
>>> We use IBM's ASMIDF to debug the similar Dignus Systems/C
>>> environment.
>>>
>>> XDC would be a good choice too...
>>>
>>> Systems/C provides DSECTs for automatic variables, and
>>> has comments that include the original C code; so if you
>>> have a nice ASM-level debugger that examines ADATA, you
>>> can do some nice debugging at the assembler level.
>>
>>
>> Unfortunately, METAL C's output is pretty awful looking, with little
>> or no referback to the original C source. That's why I was asking...
>>
>
>
> I use z/XDC. I tried the XDC C debugger for LE C/C++ and was
> disappointed. DebugTool has it's faults (and bugs) but has a better UI.
> Especially the GUI in RDz. IMO, GUIs are a better UI for debuggers if
> you have the screen real estate.
>
> I have to disagree that METAL C assembler source lacks the neccessary
> comments for debugging. Here's an example, which I think is fine...
>
> * for (hash=0, i=0; i<len; ++i) 001270
> USING @@PARMD@4,1 001270
> ICM 0,B'1111',@313len@204 001270
That looks very similar to Systems/C; when I put together
something I think is close to your example, and used the
-fasmlnno option (which displays source line numbers along
with the source) I get this in Systems/C:
* *** line 10 ***
* *** hash += key[i];
L 11,0(0,1) ; key
LA 10,0(0,0)
IC 10,0(15,11)
ALR 10,14
LR 14,10 ; hash
* *** line 11 ***
* *** hash += (hash << 10);
LR 11,14
SLL 11,10(0)
ALR 11,14
LR 14,11 ; hash
* *** line 12 ***
* *** hash ^= (hash >> 6);
LR 11,14 ; hash
...
* DSECT for automatic variables in "func"
* (FUNCTION #6)
*
@AUTO#func DSECT
DS XL80
func#hash#0 DS 1F ; hash
func#i#0 DS 1F ; i
*
(I compiled it in the default architecture, hence the use of 31-bit-only
instructions.)
I'm guessing the numbers following each instruction in Metal C refer
back to the sequence number assigned by the compiler on a
per-source-line basis?
Systems/C generates some comments that give a clue about the variables
in play... and also generates a DSECT that defines the offsets of
automatic variables. If you compile this with the -g option
(indicating you are wanting to debug the output) then variables
will reside solely in memory (at the DSECT offsets), so you can
examine them in a debugger.
Of course - then the code isn't the best in the world (constantly
loading/storing to/from memory) but - for example, here's some
of the same example compiled with -g:
* *** line 11 ***
@LM5 DS 0H
* *** hash += (hash << 10);
L 15,80(0,13) ; hash
SLL 15,10(0)
AL 15,80(0,13)
ST 15,80(0,13) ; hash
* *** line 12 ***
@LM6 DS 0H
* *** hash ^= (hash >> 6);
L 15,80(0,13) ; hash
SRL 15,6(0)
X 15,80(0,13)
ST 15,80(0,13) ; hash
Note that each source line also has an @LMnnn label, so you
could put break points on each line as you wanted by referencing the
label.
And - of course, if anyone has suggestions on how to make
this better - just let us know!
David Alcock
Metal C creates baseless code which is good but its not code that looks to be geared towards easy debugging. In my baseless code, I use the technique where you always have the entry point of the module in a register used to map constants (including the module eyecatcher) so it does double duty: you can find the program start in the current registers and it maps constants.
Metal C doesn't generate a standard OS eyecatcher. If you manage to stumble on the start of the program in a dump, it isn't going to be easily recognizable because the eyecatcher is more machine readable instead of having text. Maybe there is a way to add text via an option. For example, I would guess that the Save Area Trace of a SYSUDUMP isn't going to show the Metal C program with a good eyecatcher.
When I looked at the Metal C manual, it didn't seem to me that it includes a PRINTF function. I'd love to be corrected (on this and other points).
So I was hoping to find sessions from the last Share conference on Metal C but didn't see any where I would expect to find them:
http://ew.share.org/proceedingmod/sessions.cfm?session_id=1&conference_id=21
Kirk Wolf
macros, which it will use in generated code rather than its default.
David Crayford
You can find the complete source code for the hash function here
http://en.wikipedia.org/wiki/Jenkins_hash_function.
Interestingly, the IBM compiler has a nice optimization using 64 bit
grande instructions that save you the LR instruction if you were using
SLL. My assembler's a little rusty but I wouldn't have thought of that.
I'm impressed by the code optimizing compilers generate these days. You
would do well to produce hand crafted assembler that's as good.
* hash += (hash << 10);
SLLG 2,15,10
ALR 15,2
I haven't looked at Systems/C for a while. It gives you everything
Metal/C provides but with a complete runtime, and I prefer the syntax
for inlining assembler to the GCC clobber list syntax that Metal/C uses.
IIRC, the runtime is statically linked. It would be nice if it could
optionally be loaded dynamically (DLL) to reduce the size of the load
modules. The big value add for me was the cross-compiler which was
lightning fast compared to compiling in batch or USS.
Are Systems/C and Systems/C++ different products?
David Crayford
> This is from limited experience skimming the manual and looking at a small program generated by Metal C:
>
> Metal C creates baseless code which is good but its not code that looks to be geared towards easy debugging. In my baseless code, I use the technique where you always have the entry point of the module in a register used to map constants (including the module eyecatcher) so it does double duty: you can find the program start in the current registers and it maps constants.
>
> Metal C doesn't generate a standard OS eyecatcher. If you manage to stumble on the start of the program in a dump, it isn't going to be easily recognizable because the eyecatcher is more machine readable instead of having text. Maybe there is a way to add text via an option. For example, I would guess that the Save Area Trace of a SYSUDUMP isn't going to show the Metal C program with a good eyecatcher.
>
> When I looked at the Metal C manual, it didn't seem to me that it includes a PRINTF function. I'd love to be corrected (on this and other points).
>
> So I was hoping to find sessions from the last Share conference on Metal C but didn't see any where I would expect to find them:
>
> http://ew.share.org/proceedingmod/sessions.cfm?session_id=1&conference_id=21
>
You can use a combination of #pragma directives to get something quite
close to a standard OS eyecatcher.
* #pragma comment(copyright,\
* "HAAF130 - V1R3M0 5655-L69 \
* Copyright Fundi Software 2004, 2009. \
* Licensed Materials - Property of Fundi. \
* All rights reserved. Use, duplication or disclosure restricted.")
*
* #pragma csect(code,"PROGNAME")
* #pragma options(service("PROGNAME PK999999"))
*
* int main()
J @@CCN@1
DC XL8'00C300C300D50000' Signature
DC CL8'20091107' Compiled Date YYYYMMDD
DC CL6'093947' Compiled Time HHMMSS
DC XL4'410A0000' Compiler Version
DC XL2'0000'
DC BL1'00000000' Flag Set 1
DC BL1'00000000' Flag Set 2
DC BL1'00000000' Flag Set 3
DC BL1'11000000' Flag Set 4
DC XL4'00000000'
DS 0H
DC AL2(168)
DC C'HAAF130 - V1R3M0 5655-L69 Copyright Fundi Softwar'
DC C'e 2004, 2009. Licensed Materials - Property of Fun'
DC C'di. All rights reserved. Use, duplication or discl'
DC C'osure restricted.'
DC C' '
DS 0H
DC AL2(18)
DC C'PROGNAME PK999999'
DC C' '
Metal/C doesn't provide any runtime functions for I/O so if you want a
printf function you will have to roll-your-own I/O routines and use
vsprintf to do the formatting. It's a shame that the signature in the
prolog isn't the CSECT name!
Shmuel Metz , Seymour J.
at 09:19 AM, David Crayford <dcra...@GMAIL.COM> said:
>I'm impressed by the code optimizing compilers generate these days.
OTOH, I was impressed by the failure to generate better code, e.g., using
an RX instruction to clear a register when an RR instruction would have
sufficed.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Thomas David Rivers
> Thomas David Rivers wrote:
>
<snip>
Just to answer David's questions:
>
> I haven't looked at Systems/C for a while. It gives you everything
> Metal/C provides but with a complete runtime, and I prefer the syntax
> for inlining assembler to the GCC clobber list syntax that Metal/C uses.
> IIRC, the runtime is statically linked. It would be nice if it could
> optionally be loaded dynamically (DLL) to reduce the size of the load
> modules.
Systems/C does offer a way to dynamically load the runtime and/or
your own packages of routines. Contact me off-list for the technical
details.
The upcoming release also has features to aide in SMP/E maintenance
of those packages.
The big value add for me was the cross-compiler which was
> lightning fast compared to compiling in batch or USS.
>
Yes - people are usually rather surprised at the savings
in time/effort in a cross-compile environment.
Also - it's important to note that Systems/C offers "IBM mode",
so you can cross-compiler your IBM programs and compile them
"just like" the IBM compiler (not METAL-C, "regular" LE IBM C/C++.)
So - you can take advantage of a cross-compilation system for building
IBM-runtime-based programs.
> Are Systems/C and Systems/C++ different products?
>
Not really - Systems/C++ is an "add-on" to the Systems/C
product (you can't get Systems/C++ without Systems/C.)
It's positioned as a separate product to reduce costs for those
people who don't need C++.
Also, the Systems/C++ compiler is a different compiler than the
Systems/C compiler. The two compilers share common components
(optimizer, codegen, etc..) , but have different front-end parsers.
David Crayford
> In <4AF4CB1...@gmail.com>, on 11/07/2009
> at 09:19 AM, David Crayford <dcra...@GMAIL.COM> said:
>
>> I'm impressed by the code optimizing compilers generate these days.
>
> OTOH, I was impressed by the failure to generate better code, e.g., using
> an RX instruction to clear a register when an RR instruction would have
> sufficed.
>
Do you have anecdotal evidence that a SR or XR is actually quicker than
an LA for clearing a register? Have you timed them? I would suggest that
compiler writers have empirical evidence based upon cycle timings that
we have no access to.
Anyway, it's a micro optimization. I was talking more about the
instruction scheduling that optimizing compilers do very well to avoid
costly pipeline stalls such as the AGI and RAW issues (loop unrolling,
interleaving instructions etc). The more super-scalar the processor the
further the gap between what a compiler can produce compared to hand
crafted assembler.
David Crayford
> at 09:19 AM, David Crayford <dcra...@GMAIL.COM> said:
>
>> I'm impressed by the code optimizing compilers generate these days.
>
> OTOH, I was impressed by the failure to generate better code, e.g., using
> an RX instruction to clear a register when an RR instruction would have
> sufficed.
>
Do you have anecdotal evidence that a SR or XR is actually quicker than