Another way of looking at things is that X' serves two different roles in the assembler syntax. I became aware of this when I moved from a long career writing assembler to C++ as my primary language.
X' signifies (a.) that the constant that follows is in hexadecimal notation and (b.) a unit of storage, a byte. Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). Consider the contrast with H' which is only a unit of storage. You can say DC H'23' but you would not expect to be able to code LHI 0,H'23'. So, similarly, you can code DC 2X'23' but not LHI 0,2X'23' FWIW and OT, C/C++ separates the two functions. 0x23 represents only the quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly analogous to LHI) but if you want to define storage, you must explicitly state the unit of storage that you are defining: char foo = 0x23 or short foo = 0x23 (roughly equivalent to FOO DC X'23' and FOO DC H'35' respectively). Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Steve Smith Sent: Saturday, February 25, 2017 7:06 AM To: [email protected] Subject: Re: HLASM anomaly Have you not seen the many prior discussions of this excruciating topic? HLASM's hex notation is a PIA! 2s-complement is great for computers, not much so for humans. HLASM treats all hex constants as a 32-bit number, so if you need to specify a negative number in hex, you have to spell out all 32 bits. Shorter hex constants are positive numbers. In addition, HLASM treats hex constants sort of like strings sometimes, but mostly as numbers. Signed half-words are generated from a number internally processed as 32 bits. 65535 is out-of-range, -1 is in range; regardless of the fact they both truncate to X'FFFF'. I'd bet a considerable sum that John Ehrman covers this in his book. Only trouble is, he covers everything in that book, so it might take some time to find. :-) sas On Fri, Feb 24, 2017 at 1:24 PM, Paul Gilmartin < [email protected]> wrote: > On 2017-02-23, at 23:54, John Dravnieks wrote: > > > > Unless the assembler is redesigned to use just one expression processor, > > there will always be differences in between instruction operands and DC > > operands > > > I see little value in attempting to eliminate that difference > and much value in preserving the use of expressions as immediate > operands. > > And there are further complications - the instruction operand arithmetic > > is done using 32 bit signed binary values and it is only at the end of > the > > process where the target operand properties are considered . > > So by way of an example,16 bit immediate operands come in three flavours: > > > > Arithmetic (for example, AHI) - the value is range checked to be > > between -32768 and +32767. So AHI R1,-1 is acceptable, but AHI > > R1,X'FFFF' is not > > > But I'd expect AHI R1,X'FFFF8000' to be acceptable (somewhat surprisingly). > And this would be a compatibility impediment to the (already unlikely) > extension of expressions to 64-bit arithmetic. Compatibility could be > preserved with an idiosyncratic rule that hexadecimal terms of 8 digits > are more are sign-extended to 64 bits; hexadecimal terms of 7 digits or > fewer are 0-extended. > > > On 2017-02-24, at 01:05, [email protected] wrote: > > > > the two instructions > > > > AHI 1,-1 > > AHI 1,X'FFFF' > > - > > if they are compiled produce coding > > > > 00000000 90EC D00C 0000000C 5 STM 14,12,12 > > (13) > > 00000004 A71A FFFF FFFFFFFF 6 AHI 1,-1 > > > > 00000008 A71A FFFF 0000FFFF 7 AHI > 1,X'FFFF' > > > You're contradicting John D. here. What about: > > B EQU 65535 > AHI R1,B * Should be invalid > > A EQU X'FFFF' > AHI R1,A * ??? > > > ??? > -- gil > -- sas
