Greetings,

I've got a few questions on Metal/C (z/OS 2.1). The first one is an error I encountered while trying to compile a Metal/C program with ARCH(9). Looks like some kind of array overflow?

Exception: reason = 00000001                                                 Traceback:                                                                   Line   281 Displ 0000002C  $error                                            Line   137 Displ 00000098  Array<const OpDescAction*>::grow(int)             Line    36 Displ 0000006A  OpDesc::appendact(const OpDescAction&)            Line   151 Displ 00000026  OpcodeDescriber::appendaction(const OpDescAction&)Line  4219 Displ 0000EE5E  System370::initialize_opcodes()                   Line  5086 Displ 00000028  System370_AFP::initialize_opcodes()               Line    57 Displ 000002B6  TobeyTargets::SetTargetArchitecture()             Line   194 Displ 00000030  itb_init_cpp                                      Line   352 Displ 00000E98  itb_init                                          Line  1571 Displ 00000850  init_tobey                                        Line  1602 Displ 0000948E  UINFO_f                                           Line  1170 Displ 000002C8  process_compilation_unit                          Line   464 Displ 00000D6C  xlator_edcw                                       Line   165 Displ 000000C2  edcw                                              

The second one is that when I used to compile Metal/C programs the compiler would insert a  IABRCX DEFINE to enable relative branching instructions. It no longer does this. I was under the impression that jump instructions were faster due to less cycles through the branch predictier. Is this not the case?

Hello,

It appears we need a sample source to reproduce and investigate the issue you are experiencing compiling a Metal C program with ARCH(9).  

The compiler uses branch relative instruction and  inserts the macro IEABRCX DEFINE to enable branch relative in the macros inserted via __asm in the source.  Keep in mind having at least one __asm statement in the source is a requirement for the DEFINE statement to appear.

As an example, here is my sample source, compile command, and the header of the generated assembler output which shows the IEABRCX DEFINE statement.  I have used the latest PTF of z/OS XL C/C++ V2R1, UI26897.z2r1.

Thanks,

Visda

int asm_foo(void);

/* return 20 */
int asm_foo(void) {
   int a , b;
   a = 8;
   b = 12;
   __asm(" AR  %0,%1 "
      : "=r"(a)
      : "r"(b), "0"(a)
   );
   return a;
}

int main() {
 int ret = 0;

 ret = ret + asm_foo();

 return ret;
}

xlc -qMETAL -S myprog.c

head myprog.s

         TITLE '5650ZOS V2.1 z/OS XL C                                 X 000000
                         ./myprog.c'                                     000000
         ACONTROL AFPR                                                   000000
MYPROG   CSECT                                                           000000
MYPROG   AMODE 31                                                        000000
MYPROG   RMODE ANY                                                       000000
         SYSSTATE ARCHLVL=2                                              000000
         IEABRCX DEFINE                                                  000000
* int asm_foo(void);                                                     000001

Hi Visda,

Thanks for the reply. Download this package for the sample https://bitbucket.org/zserge/jsmn/src/6979f2e6ffa5a5723849a71dce7d22dd598c7832?at=default.

Thanks for the clarification WRT IEABRCX DEFINE.

BTW, I find these IBM DeveloperWorks forums hard to use. The UX is extreamly poor when compared to something like StackOverflow. Does the IBM C/C++ compiler team

monitor SO? If so what tags? I've found SO extreamly effective for WAS questions https://developer.ibm.com/wasdev/help/.

Hello, David,

I have made the Compiler Social Media team aware of your question regarding SO, and let someone from that team reply.

Regarding reproducing the problem ... is the intent to compile JSMN w/ MetalC?  I need to download a few other things before getting to the package you pointed me to, so may take some time.  If you have PPONLY file, -E option produces it, you can attach here; this maybe a faster way.

I've attached the PPONLY file. I've never used PPONLY before, cool!

Here are my compile options:

  -qMETAL -S -qlanglvl=stdc99 (to get restrict as a type qualifier) -qARCH=9

    + -O2

    + -O3

w/ GA PTF z/OS 2.1 XL C/C++ UK95593.z2r1

  and

latest PTF z/OS 2.1 XL C/C++ UI26897.z2r1

xlc -qMETAL -S -qARCH=9 pponly.c -qlanglvl=stdc99  -qphaseid

echo $?

0

Please let me know what I am missing in the command line invocation to reproduce the error.

Thanks.

In this case I'm not using the shell, I'm rubbing two sticks together with JCL

opt,metal,arch(9),loc(en_us.ibm-1047)ss,noseq,nomarg,sta,lo,   so,list,lang(extc99)           nosearch                       search(/usr/include/metal/)    

I can't reproduce the problem with JCL either.  I have enclosed my JCL. 

I am thinking the REGION you are allocating to your compile step is not large enough for the 2.1 compiler to allocate its tables/data structures for optimization.  Could you give it a try with unlimited or larger value for the REGION?  The REGION size for my COMPILE step is 950 M. 

I increased the REGION=0M and it fixed the problem. Happy days!

Maybe you have a bit of work to do to properly report OOM errors. Interestingly it doesn't fail with ARCH(8) or below.