What about - - compiler listings like XLC/C++ (with pseudo assembly) - Usable CEEDUMPs when there is an exception/abend - assembler inlines
Kirk Wolf Dovetailed Technologies https://coztoolkit.com On Wed, Mar 19, 2025, at 9:17 AM, JC Yao wrote: > Open XL C/C++ is being delivered in stages with incremental enhancements. > Open XL C/C++ 1.1 was bringing the Clang/LLVM infrastructure to the z/OS > platform to support more recent C++ standards needed by many open-source > applications coming onto the platform. Open XL C/C++ 2.1 added 32-bit code > generation and z/OS batch support. > We intend to keep improving the usability and features supported in the Open > XL C/C++ compiler. You can expect usability improvement with debugging and > additional key features from XL C/C++ in the next release of Open XL C/C++. > > On Mon, 17 Mar 2025 08:21:48 +0800, David Crayford <dcrayf...@gmail.com> > wrote: > > >Apologies, I fat fingered the previous email on my iPad. > > > >All our tests have been conducted from a z/OS UNIX shell, which has a > >maximum region size. Using precompiled headers won’t make much difference > >since most of the header files being read are part of the runtime and are > >not precompiled. The XLC compiler used to include precompiled header files, > >but IBM dropped them, stating they intended to improve compiler performance, > >making them unnecessary. > > > >It gets worse. The new compiler does not generate compiler listings. Neither > >does Clang, but at least it provides the llvm-objdump utility, which, when > >used with debug files, can produce something useful for debugging. > >Unfortunately, that tool isn’t included in the z/OS toolchain, so god knows > >how a customer is supposed to support their code in the field. > > > > > > > >> On 17 Mar 2025, at 7:11 am, David Crayford <dcrayf...@gmail.com> wrote: > >> > >> T sting region size is pointless. All our tests have been conducted in the > >> shell which has a maximum regi > >> > >>> On 17 Mar 2025, at 06:53, Charles Mills <charl...@mcn.org> wrote: > >>> > >>> Both tests specified REGION=0M. Here are the stats from the two compiles: > >>> > >>> Open: > >>> CPU: 0 HR 00 MIN 01.29 SEC SRB: 0 HR 00 MIN 00.03 SEC > >>> VIRT: 20K SYS: 244K EXT: 243432K SYS: 25660K > >>> ATB- REAL: 68856K SLOTS: 0K > >>> VIRT- ALLOC: 88M SHRD: 0M > >>> > >>> > >>> Legacy: > >>> CPU: 0 HR 00 MIN 00.36 SEC SRB: 0 HR 00 MIN 00.00 SEC > >>> VIRT: 80K SYS: 252K EXT: 108328K SYS: 16728K > >>> ATB- REAL: 232K SLOTS: 0K > >>> VIRT- ALLOC: 13M SHRD: 0M > >>> > >>> Charles > >>> > >>>> On Sun, 16 Mar 2025 15:48:18 -0500, Charles Mills <charl...@mcn.org> > >>>> wrote: > >>>> > >>>> Trying to hold down the noise by doing one reply for all of your great > >>>> suggestions. > >>>> > >>>> @Peter, no, did not know about .pch. The documentation is sorely > >>>> lacking. Would like to give that a try but no idea how. > >>>>> Did you run both of those tests using the same REGION value on the same > >>>>> LPAR? > >>>> Same exact virtual machine on both but I am not certain about the REGION > >>>> size. Suspect it was the same. I will look when I get back online and > >>>> possibly re-test. > >>>> > >>>> @David Crayford, agree, this product does not seem quite yet ready for > >>>> prime time. Sadly. I had hoped to move forward with the new compiler. > >>>> > >>>> @David Cole, well, both compile and run times are important. If you pay > >>>> for compile cycles, as we do, then compile CPU time is important. If you > >>>> value developer time, then compile elapsed time is important. Of course > >>>> run time is important, but harder to measure: what inputs, on what > >>>> machine? > >>>> > >>>> @Allen: noted. I will re-run the tests with larger and consistent region > >>>> sizes. I suspect they were the same, but I am not online at the moment. > >>>> > >>>> Also not sure what the OPT value was for the Open compiler test. I did > >>>> not specify, and the default does not seem to be documented :-( OPT > >>>> value was 0 for the legacy test. When I retest I will specify OPT 0. > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
