HLASM correctly refers to POPs since it is not describing each instruction. POPs uses 'treated as' for describing different operands. The term 'treated as' is used frequently with different instructions and appears to accurately describe the operand. How is it ambiguous? The limits of a 16-bit signed binary integer are well known aren't they? Not sure why you have examples of unsigned.
Sorry for getting defensive but I don't see a problem here, ...chris. -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: February-23-17 11:05 AM To: [email protected] Subject: Re: HLASM anomaly On 2017-02-23, at 11:16, Paul Gilmartin wrote: > > What are the limits on the operand of AHI? What of: > > A EQU -32768 > DC Y(A) > AHI R1,A OK, I believe. > > B EQU 32767 > DC Y(B) > AHI R1,B OK, I believe. > > c EQU 65535 > DC Y(C) > AHI R1,C OK ??? > > Is the operand of AHI treated modulo 2^16, or ? > So, I RTFM and learned little: * HLASM * HLASM Language Reference * Machine instruction statements * Operand entries * Immediate data HLASM Language Reference SC26-4940-06 ... Immediate data must be specified as absolute expressions whose range of values depends on the machine instruction for which the data is required. The immediate data is assembled into its binary representation. "depends on the machine instruction". So I need to read the PoOps, which says, for AHI: ... The second operand is two bytes in length and is treated as a 16-bit signed binary integer. ... Does "treated as" mean it's treated modulo size of field? Or ...? That seems to be a HLASM question, not a zSeries question, so I guess HLASM deserves an RCF; it shouldn't pass the responsibility (to PoOps?), which offers no clarification. Are the limits of a halfword operand: (-32768,32767) (0,65535) (-32768,65535) Other (specify)? Lore is not documentation. -- gil
