Shmuel (Seymour J.) Metz writes: > I defined R0 through R15 as GR15. While the alias LFI accepts these as > valid, IILH flags a type mismatch. It appears that HLASM treats IILH as > grande even though it only affects bits 32-47. Is this the intended > behavior? Is it documented? > > I haven't tested IILF.
I presume you mean GR32. Whoever defined IILF to HLASM in 2005 defined it as modifying the 8-byte register. When we defined LFI more recently we defined it as setting the 4-byte register as that appeared to be more appropriate for the pattern suggested by the alternative name. It appears that all of the older instructions IILL, IILH, IIHL and IIHH were defined for OPTABLE(ZOP) before the assembler added support for distinguishing the register types, but the definitions were updated later to treat them as modifying the 8-byte register in the same way as for IILF. It would seem to be logical for IILL, IILH and IILF to accept either a 32-bit register type or a 64-bit register type in this case, as the underlying concept is ambiguous. Unfortunately, the existing TYPECHECK processing assumes an instruction only expects one or the other. If any symbol of type GR32 or GR64 has been defined, the check will only accept the right one. This also means that if the existing definitions are changed, this could cause new warnings for existing programs, which is considered unacceptable for compatibility reasons. So I think you're stuck with that limitation unless HLASM in the future implements a type checking extension which allows either GR32 or GR64 for the same instruction, as needed in this case. Jonathan Scott, HLASM IBM Hursley, UK
