- This patch (is one in a series of patches) which introduces HLASM Parser support (for the first parameter of inline asm statements) to LLVM (main RFC here)
- This patch in particular introduces HLASM Parser support for Z machine instructions.
- The approach taken here was to subclass AsmParser, and make various functions and variables as "protected" wherever appropriate.
- The HLASMAsmParser class overrides the parseStatement function. Two new private functions parseAsHLASMLabel and parseAsMachineInstruction are introduced as well.
The general syntax is laid out as follows (more information available in HLASM V1R6 Language Reference Manual - Chapter 2 - Instruction Statement Format):
- TokA is referred to as the Name Entry. This token is optional
- TokB is referred to as the Operation Entry. This token is mandatory.
- TokC is referred to as the Operand Entry. This token is mandatory
- TokD is referred to as the Remarks Entry. This token is optional
- If TokA is provided, then we either parse TokA as a possible comment or as a label (Name Entry), Tok B as the Operation Entry and so on.
- If TokA is not provided (i.e. we have one or more spaces and then the first token), then we will parse the first token (i.e TokB) as a possible Z machine instruction, TokC as the operands to the Z machine instruction and TokD as a possible Remark field
- TokC (Operand Entry), no spaces are allowed between OperandEntries. If a space occurs it is classified as an error.
- TokD if provided is taken as is, and emitted as a comment.
The following additional approach was examined, but not taken:
- Adding custom private only functions to base AsmParser class, and only invoking them for z/OS. While this would eliminate the need for another child class, these private functions would be of non-use to every other target. Similarly, adding any pure virtual functions to the base MCAsmParser class and overriding them in AsmParser would also have the same disadvantage.
- This patch doesn't have tests added with it, for the sole reason that MCStreamer Support and Object File support hasn't been added for the z/OS target (yet). Hence, it's not possible generate code outright for the z/OS target. They are in the process of being committed / process of being worked on.
- Any comments / feedback on how to combat this "lack of testing" due to other missing required features is appreciated.