Provide the option to make new RENT Assembler module against SIIS.

I agree with IBM HLASM development that this should be rejected. This is something that should be handled best by the customer in their development environment, by creating their own macros that can insert 256 (or more) bytes as needed.

We have communicated with the requester via email to clarify this requirement, as the references to the RENT option were unclear.

It appears that what is being requested is an option similar to the WORKFILL option in VS Fortran which inserts 256 bytes of padding between read-write data fields and executable code within the same control section, in order to ensure that data and instructions end up in separate cache lines, to avoid the potential performance impact of "Store Into Instruction Stream" processing, where a data store causes an overlapping instruction cache line to be flushed and replaced.

However, VS Fortran generates its variable data and code areas itself, so it knows what storage is used for variable data and what storage is used for code. HLASM has no such information available, as HLASM data definitions (DC and DS) do not indicate directly whether the field is constant or may be modified. During the first pass, information about read-write or read-only storage is only known to HLASM at the section level (for RSECT) or for all control sections (if the RENT option is used). HLASM is able to track which symbols are referenced in operands which are modified (as indicated in the cross-reference) but cannot associate these with specific locations until the second pass, at which point all addresses have been resolved so it is not possible to insert new definitions.

If the customer's programs follow conventional patterns which make it possible for a source scanning program to identify the boundary between data and code automatically, then it may be possible to insert dummy padding definitions at such points to ensure separate cache lines, or at least to identify suitable points to make such changes manually. It is of course possible that this will have side-effects, such as causing addressability errors because of increasing the amount of data and code.

Another possibility is that if such boundaries are always preceded by a specific sequence of instructions (such as CNOP 0,4 in this case) then it may be possible for a skilled programmer to use OPSYN to intercept such instructions and detect such sequences, inserting extra padding where required.

If such boundaries typically occur in code generated by macros, it may be quite simple to change the macros in these cases. If this can be done for new hardware, it should probably also be done for older hardware as well, as the hardware has been optimised for many years to assume that instructions and data should normally be kept separate, although the relative overhead of transferring data between one and the other has become much more significant recently.

As far as we can see, it is not feasible to address this requirement in HLASM. This is because it effectively requires implicit modifications to the source program at points which cannot be determined from the information available to HLASM in the source code. We are therefore expecting to reject this RFE in the near future, but for the moment we are leaving it open in case anyone wishes to discuss this specific problem any further.

As I read this, I believe that this is something that should be handled by the requester in their build environment. Their JCL or other invocation set-up should be changed to specify RENT via ASMAOPT, which cannot be overridden by PARM.

Since the customer is experiencing performance problems, I would suggest restating this as a z/OS requirement to provide a performance analysis tool that allows a customer to identify these non-reeentrant modules and those with cache issues.