> GOD I hope that's not what he means! Especially not the part where
> you ORG back over an instruction to make it behave differently than
> than coded! Yikes! Did we just find another "cowboy?"
*Whoa Nelly!*
No, you are reading too much into my thoughts. I am saying that
sometimes we code macros which do 'special things'. Macros that we keep
track of and know will be replaced latter. I was putting this item into
the possibility of being in one of those macros.
Tony Thigpen
Ed Jaffe wrote on 10/10/2017 02:18 PM:
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!
Ed made it clear that this isn't about this particular instruction in
this particular case, but rather is a matter of programmer management
and/or technical means to catch out bad practices.
To me, as a vendor, this is actually a good idea.
Which part is a good idea? I trust you don't mean sneaking in code
from a higher architectural level than allowed by policy...
GOD I hope that's not what he means! Especially not the part where you
ORG back over an instruction to make it behave differently than coded!
Yikes! Did we just find another "cowboy?"
