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

Reply via email to