On 9 August 2012 12:52, David Stokes <[email protected]> wrote: > As other amusing psssibilities you can always use this old trick to avoid the > problem > > UNPK CS00ABND_WORK(9),TGA_TABCOD(5) Hex convert > NC CS00ABND_WORK(8),=8X'0F' > TR CS00ABND_WORK(8),=C'0123456789ABCDEF' > > which admittedly has a slight and mostly irrelevant overhead, or of course > > UNPK CS00ABND_WORK(9),CS00ABND_ABCODE(5) Hex convert > LARL R15,TRHEX > TR CS00ABND_WORK(8),0(R15) > > LARL won't be bothered by negative offsets. Of course, ensure the halfword > boundary.
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. TR and TRT have several oddities of definition that doubtless seemed like a good idea at the time, but which have surely been nightmares to implement over the years. Tony H.
