Paul Gilmartin wrote: > On 2018-04-23, at 01:41:27, Jonathan Scott wrote: > > 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
The second operand location must be addressable using 12-bit addressing from the original set of base registers. > 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. The problem is that calculations of the form A-B+C evaluated using 31-bit signed arithmetic can sometimes overflow 31 bits for an intermediate result yet give a correct final result (equivalent to performing the calculation in a different sequence). If HLASM rejected any displacement calculation that caused overflow for an intermediate result, this could break existing code. The only "safe" way to handle such calculations is to evaluate them using at least one bit more than the final result length then to check for overflow afterwards. This would mean HLASM would have to evaluate displacement expressions using 33-bit values or more in order to cover this obscure case, which seems disproportionately complicated (and note that HLASM cannot yet use 64-bit registers in common code because it still supports execution on CMS in ESA mode). When this problem was mentioned some years ago, I did sketch a solution involving using an additional single-bit field to track overflow for intermediate results, but in the long run we were hoping to move to 63-bit signed expression evaluation, so we didn't investigate that any further. (Given current constraints on budgets for development resources, that doesn't seem likely to happen soon). Jonathan Scott IBM Hursley, UK
