I suggested the "omitted uses implied length" syntax since RISBG etc. instructions already have "omitted implies zero" for the fifth operand.
Robert Ngan DXC Luxoft -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Jonathan Scott Sent: Friday, October 1, 2021 03:21 To: [email protected] Subject: Re: Vector Instructions The HLASM team also failed to spot this oddity in the syntax at the time, partly because the I3 field was not described clearly as "length", even though that is what it is in effect. Dan's concern about adding extra function to the I3 field would not have been a problem for HLASM (provided that the split was on bit boundaries) because HLASM can for example define a 5-bit length field and a 3-bit flag field, even though at present all operand fields start and end on 4-bit boundaries. Any new extra function field could have been defined as a separate operand. Unfortunately the only way to implement the standard syntax would be to add new mnemonics, as we cannot change the existing definitions for compatibility reasons. We might still end up doing something like that. Robert's alternative suggestion of assuming the implied length if omitted would require new unique parsing logic in this case and would make it difficult to extend this instruction in future. Dan Greiner wrote: > Interesting comment, Robert. > > Assuming that the storage operand field of VPKZ/VUPKZ is defined with > an appropriate length, you make a valid point. > > Had I been been paying closer attention when this was architected, I > might have suggested that the VSI instruction format (added > specifically in support of VPKZ and VUPKZ) incorporate the length as > part of the second operand ... that is, an L2 field instead of an I3 > field. That way, you could code the instruction the way you suggested, > or as is done for other storage operands with an embedded length, > e.g., > > vupkz 1,storage_op > vupkz 1,storage_op(23) > vupkz 1,543(21,12) > > However, as is obvious with recent changes in the architecture, IBM > tends to sneak new features into previously reserved operand bits. If > some future enhancement added function to the I3 field, the suggestion > I made above could become awkward. Jonathan Scott, HLASM IBM Hursley, UK
