Correction:

DO    WHILE,TROT,R14,R2,B'0001',1
ENDDO

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On 
Behalf Of Steve Smith
Sent: 11 October 2017 23:19
To: [email protected]
Subject: Re: Rehabilitated TROT Routine (Was: Detection of Compile-Time 
Self-Modifying Code)

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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Reply via email to