Bruce Black wrote:
Here at PSI, we ended up rewriting many routines that had worked for
decades because TR/TRT went from an ultra-fast, hardware
implementation to a slow, millicode implementation. For short
strings, we found that TR/TRT could be replaced by a loop of
equivalent hardware-implemented instructions that ran considerably
faster! Apparently, the "new" workloads IBM used for their modeling
don't use TR/TRT very often.
On the z9 systems (and maybe on the z890/z990, I forget), the
translate instructions aren't even millicoded anymore. They have been
offloaded to the same co-processor that handles the encryption
instructions on those systems. Whether this improves the speed, I
couldn't say.
Actually, the TR/TRT instructions, from z900/z800 up through z9, use a
hardware translation engine which is driven by millicode. Millicode
fetches the the first operand and stores the result back, but the
hardware engine automatically fetches the translation table in the
second operand itself. The engine is very fast for long translations; it
can translate two bytes per clock cycle. However, there is also a
signficant start-up cost (millicode set-up and fetching the entire
256-byte translation table). Because of this relatively long start-up
delay, for short lengths, millicode does the translation itself for up
to length 8 via a manual process. The millicode is highly optimized for
performance. Nevertheless, there is a signficant start-up delay in just
having millicode get started.
Therefore, in current hardware models, it makes sense to have normal
software do the operation for short lengths. Obviously, as part of this
you can use all the normal coding tricks including loop unrolling. The
actual optimization of the assembler code will vary from one generation
of hardware to the next.
It is my understanding that for a future generation system
(unannounced), TR/TRT will move out of the translation engine and into
pure millicode. Some additional hardware assists will be provided to
speed up the millicode. This will help the short length cases, but it
will still be better for very short lengths to do them with software.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
