On 10 October 2017 at 09:45, Tony Thigpen <[email protected]> wrote: > You got me curious as to 'why?' > > So, I went back to different versions of the PoP. > > The mask setting was not available at an earlier PoP, but according to the > newer PoP, it will still be ignored if a machine option is not installed. > > The mask is is playing with could be considered one of those 'it may speed > it up' options if the new mask keeps him from having to restart his TROT > process because the stop character is not really a stop character. There is > not enough code to know if that is true or not. > > So, basically, this code seems to cause no harm if ran on an earlier > machine, but could speed up the process if a newer machine is being used.
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. > All up-side, with no down-side. 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... Tony H.
