> Replication would then expand outside of the instruction and into the > instruction stream
Not necessarily. AHI R1,2X'FF', were it valid, would presumably generate exactly the same machine code as the valid AHI R1,X'FFFF'. One could, for example, write a series of macros (with names for example like AHI@) that would accept immediate operands with replication factors exactly as the OP wished, and assemble them into valid machine code. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Steve Thompson Sent: Thursday, February 23, 2017 4:56 AM To: [email protected] Subject: 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 instruction fetch (IF) using the PSW's Instruction counter (IC). When an instruction is fetched, the IC is advanced by the length of the instruction -- which is based on the OP code (it defines the length of the instruction). Accordingly, there is nothing in the instruction to tell IF that this instruction has a different length for updating the IC. It would help to read the Principles of Operations manual for more than just the instructions that you want to use. Understanding how the machine actually works can keep you out of trouble and make use of nuances at the same time. Regards, Steve Thompson On 02/22/2017 04:18 PM, Melvyn Maltz wrote: > Immediate operands won't accept a duplication factor...why not ? > Can't find a reason in the HLASM manual > > Try these... > CFI R1,4X'FF' > CFI R1,X'FFFFFFFF' > CFI R1,-1 > AHI R1,2X'FF' > AHI R1,X'FFFF' > AHI R1,-1 > > Melvyn Maltz >
