On 15 May 2014 15:00, Blaicher, Christopher Y. <[email protected]> wrote: > The problem with TRT is it validates the whole TRT table before it starts to > do the TRT.
I think you are speaking of access exceptions for the table (the second operand), which because of the instruction definition can require an extraordinary amount of setup, and perhaps a trial execution. Access failures are not to be recognized for table bytes not actually referenced, and of course this depends on the content of the first operand. The presumably worst case is when the notionally 256-byte table straddles a page boundary. EDIT and EDMK can also incur this problem. > I believe TRTE and TRTRE also suffer from that, but also they are > milli-coded, or is it micro-coded, which incurs a > non-trivial amount of instruction startup and termination time. TRTE and TRTRE do not suffer from the TRT table access problem, because "Access exceptions for any byte of the function-code table specified by general register 1 may be recognized, even if not all bytes are used". > The overheads are similar to MVCL compared to MVC used in a loop. A loop of > MVC's will reduce the CPU time of > a routine until you get to close to moving 32K at a time. If you are moving > more than 32K at a time, then MVCL > can win. I use MVCL a lot even for very small moves where the length is not known at assembly time. But I know my environment and its performance requirements, and often judge the relative elegance, generality, and programmer-readability of such an instruction to override what small performance gain there might be to multipathing and/or loops. Tony H.
