On 9 August 2012 15:43, Robert A. Rosenberg <[email protected]> wrote: > At 14:06 -0400 on 08/09/2012, Tony Harminc wrote about Re: Printing a > return code: > > >> But as the book says, "Significant performance degradation is possible >> when, with DAT on, the second-operand address of TRANSLATE designates >> a location that is less than 256 bytes to the left of a 4K-byte >> boundary. This is because the machine may perform a trial execution of >> the instruction to determine if the second operand actually crosses >> the boundary." To say nothing of the similar overhead in testing for >> fetch protection, which one imagines would be rolled into the same >> trial execution. > > > Unfortunately there is little that can be done to insure that the > boundary is not crossed. The only thing I can think of the insure it > is to first make sure that there is addressing in the CSECT such that > the table is all on one page and second in the binder to make sure > the CSECT is page aligned. Otherwise the CSECT can end up aligned so > as to have the table overlap a page boundary.
Page aligning the CSECT when using the OP's trick may make a trial execution more likely. In the typical case where the table is in the middle of some code space, the page to the left of the "main" one probably will be in real storage, and presumably the test for that (and perhaps key controlled protection) would be a good deal faster than running a trial execution. It's the case of pushing the table notionally to the left of the start of the CSECT that is much more likely to lead to its actually being an unreferenceable page, which then requires the trial run only to find out that no bytes in the left page are referenced. Tony H.
