On 11 October 2017 at 12:16, Ed Jaffe <[email protected]> wrote: > On 10/10/2017 1:52 PM, Ed Jaffe wrote:
> Thanks to input from Tony Harminc and others, we have rehabilitated this > routine so that it now conforms to standards: > > | XGR R0,R0 Ensure no stop char match > | DO UNTIL=NO Do for all chars > | TROT R14,R2 Convert to hex > | ENDDO , EndDo What do the DO and ENDDO macros do here? Do they generate a test for CC=3 and loop? That seems like a lot of assumption to build into a DO macro... > It looks a lot better without the ORG/DC/ORG and nonsense comment about > OPTABLE(YOP) being an issue. Best of all, it works!!! BTW, there is another little gotcha wrt TROT and friends that actually bit a colleague here not long ago. "The translation table is treated as being on a doubleword boundary for TRANSLATE ONE TO ONE and TRANSLATE ONE TO TWO. For TRANSLATE TWO TO ONE and TRANSLATE TWO TO TWO, the translation table is treated as follows: • When the ETF2-enhancement facility is not installed, the translation table is treated as being on a 4K-byte boundary. • When the ETF2-enhancement facility is installed, the translation table is treated as being on a doubleword boundary. The rightmost bits of the register that are not used to form the address, which are bits 61-63 in the doubleword case and bits 52-63 in the 4K-byte case, are ignored but should contain zeros; otherwise, the program may not operate compatibly in the future." Note that it "is treated as being on a bbb boundary" - not "must be on a bbb boundary". You can happily put your table on a fullword or worse boundary, and the instruction will happily ignore some low bits in the table address, and you will tear your hair for some time over why your hex digits are weirdly wrong. Worse, if your table is defined on an incorrect boundary it can work fine for a long time, and then a reassembly can suddenly turn your hex all wonky. e.g. DOUBLE DC D'something' or AD(somewhere) or the like TABLE DC C'F0F1F2...' is all working, and then you insert a DC F'something' after DOUBLE... Or much higher up and out of view, of course. Tony H.
