On 10 October 2017 at 14:18, Ed Jaffe <[email protected]> wrote:
> On 10/10/2017 10:47 AM, Tony Harminc wrote:

>> Ironically, for this example, assuming the table is the standard one
>> that converts each byte to its 2-byte hex character representation,
>> the mask bit will never make any difference to the processing at any
>> architectural level. You *do* have to ensure that R0 contains a value
>> such as zero that is not in the table, but it is, as you say, only a
>> possible performance advantage. But there can be no restarting or
>> looping because CC 1 cannot be set in this case.
>
> The source hex bytes can contain any arbitrary values 00-FF. There is no
> value for R0 that can avoid the stoppage. He would have needed some
> exception routine to handle CC=1, manually MVC in two bytes appropriate to
> the stop character, advance the pointers, and loop back. That exception code
> didn't exist, so this routine simply fails on older machines. Even if that
> CC=1 exception code was there, I would still be upset about the use of
> ORG/DC to update the instruction!

Yeah, I thought that for a long time too, and avoided the obvious and
convenient use of TROT to do hex output conversion. Until I read the
book carefully a while back:

"When the ETF2-enhancement facility is not installed, or when the
test-character-comparison control is zero, each function character
selected from the translation table is compared to a test character in
general register 0, and, unless an equal comparison occurs, is placed
at the first-operand location.
...
The lengths of the operand and test characters are as follows:
...
For TRANSLATE ONE TO TWO, the second-operand characters are single
bytes, and the first-operand and test characters are double bytes.
...
For TRANSLATE ONE TO TWO and TRANSLATE TWO TO TWO, the test character
is in bit positions 48-63 of general register 0. "

So it's the table *output* characters that are matched against the
character in R0 - not the input. For TROT that character is a 16-bit
one, and your hex table is only 512 bytes long, is sparse, and is not
going to contain 0000 or any of the other 65279 values you could
choose arbitrarily to avoid ending prematurely with CC=1.

Tony H.

Reply via email to