Re: HLASM anomaly

Fellow listers I used to develop and maintain HLASM and there were lots of internal discussions about how to handle items like 16 bit immediate opearnds. One point is that internally the assembler has an expression processor for instruction operands, and it has another one for DC operands -

Re: HLASM anomaly

On 2017-02-23, at 23:26, Webster, Chris wrote: > 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 >

Re HLASM Anomaly

Another reason not to allow DC-type operands in immediate operands: consider AHI 0,(N)X'F' The Assembler can't tell that the instruction is indeed 4 bytes long. I suppose it could do some acrobatics, but the cost vs. value seems excessive. John

Re Immediate operands

Immediate operands don't support duplication factors because they're not immediate. Consider all the places in statements where a numeric value can occur -- constructs like BALR 2FL.41'7',3BL.4'101' -- I guess we never thought of documenting that restriction because we never thought someone

Re: HLASM anomaly

On 2017-02-23, at 11:16, Paul Gilmartin wrote: > > What are the limits on the operand of AHI? What of: > > AEQU -32768 > DC Y(A) > AHI R1,AOK, I believe. > > BEQU 32767 > DC Y(B) > AHI R1,BOK, I believe. > > cEQU 65535 >

Re: HLASM anomaly

On 02/23/2017 01:16 PM, Paul Gilmartin wrote: On 2017-02-23, at 10:31, Steve Thompson wrote: Informative? Or Warning? Do you then disagree with warnings on multiple base-displacement resolutions? I sometimes run into this, and can't figure out why the assembler even issued the message.

Re: HLASM anomaly

On 2017-02-23, at 10:31, Steve Thompson wrote: >>> >> Informative? Or Warning? Do you then disagree with warnings on >> multiple base-displacement resolutions? > > I sometimes run into this, and can't figure out why the assembler even issued > the message. But when it happens I do verify that

Re: HLASM anomaly

On 02/23/2017 10:09 AM, Paul Gilmartin wrote: On 2017-02-23, at 07:57, Steve Thompson wrote: Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they

Re: HLASM anomaly

On 2017-02-23, at 07:57, Steve Thompson wrote: > Ah, I see why you all are having a problem with this. > > And me, being an old ALC programmer, this is intuitively obvious. In fact, > there are several changes to HLASM that I disagreed with, because they then > caused programs I had written

Re: HLASM anomaly

Yeah, I just answered another post on this. It explains my error -- I was reading fast and thinking 1 byte immediates, not the multi-byte of the newer instructions. Still stuck in pre-z/Arch instructions. But, I am slowly using the newer ones. Regards, Steve Thompson On 02/23/2017 09:28

Re: HLASM anomaly

Ah, I see why you all are having a problem with this. And me, being an old ALC programmer, this is intuitively obvious. In fact, there are several changes to HLASM that I disagreed with, because they then caused programs I had written earlier to start getting informative messages, where they

Re: HLASM anomaly

From: "Steve Thompson" Sent: Thursday, February 23, 2017 11:55 PM What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction Why? It is an Immediate

Re: HLASM anomaly

What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by