On 2018-04-23, at 01:41:27, Jonathan Scott wrote: > We are aware of various limitations with 20-bit support in USING, > including dependent USING, which were previously discussed on this > list in 2012. > > A workaround for this specific case is to subtract some value from both > addresses so that the matching offset lies within the 12-bit addressable > range, for example as follows: > > USING TinyArea-4000,Byte-4000 > Is there any limit to that offset? Might one use: USING TinyArea-4000000,Byte-4000000 > > > It would have been possible for HLASM to provide a simple fix for the > 20-bit dependent USING case but we were holding it back because we felt > that compatibility considerations could limit our options for a more > general solution which was being designed at the time, but which never > got approved because of concerns that it would require incompatible > changes to the USING headers, the USING map and the corresponding ADATA > records. > The hardware folks have freedom to provide new addressing modes with larger reach at their whim. For HLASM to enforce limits at USING time is shortsighted. Only base-displacement should perform such enforcement.
And IIRC I've posted here a case where HLASM allows a base-displacement resolution which is unconditionally incorrect in AMODE 64 and algebraically incorrect in AMODE 31 or 24. I believe this is due to ignoring an overflow. HLASM should report the error and users should accept that (extremely improbable) code relying on the loophole is incorrect. -- gil
