Oppolzer - Informatik / Blog

I have the impression that you still don't understand it, so I'll give you two
examples:

First:

LABEL  DIAG  3,4,5

will generate

LABEL  LA    3,5(4,0)    Diagnose
       ORG   LABEL
       DC    X'83'
       ORG  ,

Second:

       DIAG  3,4,5    - without a Label

will generate

       LA    3,5(4,0)    Diagnose
       ORG
       DC    X'83'
       ORG  ,

so, as you know can see (I hope), the X'83' will not overwrite the op code of
the LA in this case.

This is just plain wrong. No error or warning for the user in this case.

Kind regards

Bernd




Am 21.12.2013 16:21, schrieb Bernd Oppolzer:
> Am 21.12.2013 16:06, schrieb P.G.:
>> On 2013-12-21, at 05:51, J.G. wrote:
>>
>>> EJ's macro can of course be written in the form
>>>
>>>         MACRO ,
>>> &LABEL  DIAG  &R1,&R2,&I1
>>> &LABEL  LA    &R1,&I1.(&R2.,0)    Diagnose
>>>         ORG   &LABEL
>>>         DC    X'83'
>>>         ORG  ,
>>>         MEXIT  ,
>>>         MEND  ,
>>>
>>> and this form, which delegates the location-counter arithmetic to the
>>> assembler, seems to me to be at once clearer and less error-prone.
>>>
>> Agreed.
> The first ORG only does what it is supposed to do,
> if there is a label on the macro call, and so the ORG *-4
> which EJ provided in his original version is better.
>>
>>> Dijkstra's epigoni have conditioned many people to avoid the use of
>>> labels whenever possible, even at the expense of real ugliness, not
>>> present here; but the use of an already present label in this way
>>> seems to me to be entirely benign.   Moreover, their judicious use
>>> often makes it possible to avoid what T.H. has just called
>>> "fancier ORGs".
>>>
>> Agreed.  But the ORG without argument may not do what you desire:
>> It sets the location counter to the previous highwater mark, which
>> may, because of prior ORGs, be elsewhere than the end of the LA.
> The second ORG indeed is subject to the problem you described,
> so, again, the version that EJ originally provided (ORG *+3), is better.
> Inside macros, there are different rules for good, bad and ugly code.
>> -- gil
>>
>