Well, Ed's not answering, but I know the answer. He presented his structured programming macros at SHARE at least once. The UNTIL=NO means the usual conditional, i.e. "Not Ones", or "Not Overflow". Neither is English-sensible after TR*, but it gets the right condition check. Nothing is being assumed.
The equivalent I have is DO WHILE,TROT,R14,R2,B'0001' -- the last operand could be O, or it could be an UNTIL loop with NO (and any other typical condition). But we allow bare condition-code masks, too, especially for cases where the mnemonics aren't really mnemonic. Re table alignment: One of the strangest things in the architecture, for sure. Feels kind of like those fixes I've sometimes made that I didn't quite get to completely finish. On Wed, Oct 11, 2017 at 3:05 PM, Tony Harminc <[email protected]> wrote: > 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... > ... > 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. > -- sas
