On Fri, May 18, 2012 at 3:54 AM, Robert AH Prins <robert.ah.pr...@gmail.com> wrote: > On 2012-05-17 11:42, Robert AH Prins wrote: >> >> On 2012-05-17 11:14, Bernd Oppolzer wrote: >>> >>> I would like to add: >>> >>> with the previous compiler, CALL PLIMOVE enabled us to force the >>> generation of >>> MVCL. >>> >>> Using, for example >>> >>> CALL PLIMOVE (ADDR (target), ADDR (source), length); >>> >>> the compiler generated MVCL, >>> >>> but coding >>> >>> target = source; >>> >>> (if applicable), or BY-NAME-assignments, the compile generated MVCs etc. >>> >>> Now, with V3.9, the compiler generates the same in the two cases, >>> that is MVCs or MVC loops, so we have no possibility to force the >>> generation of MVCL. AFAIK, my co-workers didn't play with the ARCH >>> options, so far. TUNE is TUNE(2), again AFAIK. >> >> >> The TUNE option has been removed from the V4.1 anyway. >> >>> I have other projects at the moment, so I had not much time so far to >>> investigate this. But remember: the problem showed up by a Strobe Report, >>> so it seems to be significant. >>> >>> But: if PLIMOVE does no better than a simple assignment, using PLIMOVE >>> seems to make no sense to me. >>> >>> In a certain way, this problem is somewhat different from the first >>> problem in this thread. >>> >>> Robert complained about the optimizer doing a bad job, that is: some >>> instructions are generated that are useless, and others are questionable. >>> >>> But here we have a simple instruction of the HLL (PLIMOVE) which I expect >>> to be implemented using the best instructions the machine provides. If >>> this turns out not to be the case, this is IMHO simply a bug, not only >>> a flaw of the optimizer. The programmer already did some kind of >>> optimization >>> him- or herself, when he or she decided to use PLIMOVE. He or she may >>> well >>> expect that the compiler generates the best available machine instruction >>> for this HLL instruction. >> >> >> You hit the nail right on the head! But I do remember that there was a >> APAR that >> explains why the MVCL was removed again. I can't point you to it as the >> link to >> the PL/I APARs has gone 404. > > > It's back and I have to correct myself, I've only managed to find a APAR > telling that the generation MVCLE 's was removed > <http://www-01.ibm.com/support/docview.wss?rs=619&context=SSY2V3&q1=%2b5655H3100+%2br370&uid=swg1PK79325&loc=en_US&cs=utf-8&cc=us&lang=all> > > Robert > -- > Robert AH Prins > robert(a)prino(d)org > >From the APAR, dated 2009-02-02: Problem summary **************************************************************** * USERS AFFECTED: Enterprise PL/I users with code that has * * assignments to NONVARYING CHAR strings where * * the source and/or the target has a length * * not known at compile time * **************************************************************** * PROBLEM DESCRIPTION: The 3.6 and later releases of * * Enterprise PL/I generated a MVCLE * * instruction to perform such * * assignments. Unfortunately, while this * * led to a much shorter set of * * instructions, it also led to * * significantly worse performance. * **************************************************************** * RECOMMENDATION: * **************************************************************** The compiler has been changed so that it no longer generates MVLCE's
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
