Re: Long displacement dependent USINGs now supported
On 11/17/2021 1:36 AM, Jonathan Scott wrote: We have just shipped the PTFs for APAR PH42050 which allows a dependent USING instruction to be resolved using a 20-bit signed displacement provided that the specified OPTABLE is one which supports instructions with that capability. | HH HH AA NN NN KK KK | HH HH NNN NN KK KK | TT HH HH AA AA NN KK KK | TT HH HH AA AA NN NN NN KK KK | TT HH HH AA AA NN NN NN KK KK | TT NN NN NN KKK | TT NN NN NN KKK | TT HH HH AA AA NN NN NN KK KK | TT HH HH AA AA NN KK KK | TT HH HH AA AA NN NNN KK KK | TT HH HH AA AA NN NN KK KK | TT HH HH AA AA NN N KK KK | | | YY YY UU UU | YY YY UU UU | YY YY OO OO UU UU | YY YY OO OO UU UU | YY YY OO OO UU UU | OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY OO OO UU UU | YY | YY UU -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long displacement dependent USINGs now supported
Ref: Your note of Wed, 17 Nov 2021 18:09:47 + gil writes: >Also, decades ago, I found that (something like): >PSWMAP DSECT > ... > USING PSWMAP-SVCOPSW,R0 > >quietly behaved as if I had coded: > USING PSWMAP,R0 > >Experts conceded that the behavior is indefensible except >on grounds of compatibility with existing art. Note that this sort of offset USING in low storage can be achieved using a dependent USING, for example (assuming LOWSTG is a DSECT and SVCOPSW is an equated offset): USING LOWSTG,0 then USING PSWMAP,LOWSTG+SVCOPSW or USING PSWMAP-SVCOPSW,LOWSTG Jonathan Scott, HLASM IBM Hursley, UK
Re: Long displacement dependent USINGs now supported
gil writes: >Also, decades ago, I found that (something like): >PSWMAP DSECT > ... > USING PSWMAP-SVCOPSW,R0 > >quietly behaved as if I had coded: > USING PSWMAP,R0 > >Experts conceded that the behavior is indefensible except >on grounds of compatibility with existing art. Yes, but compatibility is critical. In this case, as a warning message ASMA302W is now being issued, we are allowed to fix it if we can work out how to change the relevant internals (which is not trivial). However, there are many things that we cannot fix without adding compatibility options that create more complexity than the original solution. For example, I find it very annoying that negative SETA symbols are substituted without their minus sign. Jonathan Scott, HLASM IBM Hursley, UK
Re: Long displacement dependent USINGs now supported
Ref: Your note of Wed, 17 Nov 2021 09:17:36 -0700 gil writes: > Does that affect generated code, or even ASMADATA? Might > any users depend on the misbehavior? The Active Usings headings and the Using Map are just additional information in the listing (and ADATA) so any errors in the code to produce them does not affect the generated code. The incorrect calculations for dependent USINGs with non-zero based section offset had apparently been around at least since the SLAC modifications were integrated into HLASM release 1 in 1991. Jonathan Scott, HLASM IBM Hursley, UK
Re: Long displacement dependent USINGs now supported
On Nov 17, 2021, at 02:36:12, Jonathan Scott wrote: > ... > When we resumed this item recently, we found that the logic to > handle the dependent USING base address and range in the Using > Map and Active Usings headings incorrectly assumed that any > dependent USING would be basing the start of a section, which > meant that various fields were being incorrectly calculated. > This has now been fixed. > Does that affect generated code, or even ASMADATA? Might any users depend on the misbehavior? I recall many years ago IBM fixed a clear code generation bug which we had Been deliberately avoiding. But our development manager required that we compare all our SYSLINI after and before the APAR to prove we hadn't unwittingly depended on the defect. Also, decades ago, I found that (something like): PSWMAP DSECT ... USING PSWMAP-SVCOPSW,R0 quietly behaved as if I had coded: USING PSWMAP,R0 Experts conceded that the behavior is indefensible except on grounds of compatibility with existing art. Nowadays it's no longer quiet, but: ASMA302W USING specifies register 0 with a non-zero absolute or relocatable base address Feckless. A more honest message text would be: ASMA302W USING interpreted incorrectly for compatibility with historic behavior XRR2,R2 USING PSWMAP-SVCOPSW,R2 ... ehaves correctly. > https://www.ibm.com/support/pages/apar/PH4205 -- gil
Re: Long displacement dependent USINGs now supported
That's great! Explaining things like "ST USING STATUS_TABLE+4000,STATUS_DESC+4000 " makes people suspect me of witchcraft. sas
Long displacement dependent USINGs now supported
We have just shipped the PTFs for APAR PH42050 which allows a dependent USING instruction to be resolved using a 20-bit signed displacement provided that the specified OPTABLE is one which supports instructions with that capability. It was apparently intended that this support should have been included as part of the original 20-bit displacement support in around 2003, but it was not implemented at that time. We prototyped the support in 2013 but ended up setting it aside for further research, partly because of unexpected results in the Active Usings headings and Using Map. When we resumed this item recently, we found that the logic to handle the dependent USING base address and range in the Using Map and Active Usings headings incorrectly assumed that any dependent USING would be basing the start of a section, which meant that various fields were being incorrectly calculated. This has now been fixed. For details, see the IBM Support page for APAR PH42050 (which at the time of writing has yet to catch up with the fact that PTF UI78085 for HLASM on z/OS is also now closed and available): https://www.ibm.com/support/pages/apar/PH42050 Jonathan Scott, HLASM IBM Hursley, UK
