No one would be obligated to use 64-bit set symbols. There could be an assembler option to produce "old" or "new" ASMADATA/disallow or allow 64-bit set symbols. ASMADATA has "version" indicators in every record. This is a solvable problem.
Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, July 04, 2014 9:27 AM To: [email protected] Subject: HLASM doubleword set-symbol arithmetic On Fri, 4 Jul 2014 11:18:12 -0400, John Gilmore wrote: > >..., but z/OS is still full of gaps in >the facilities it makes available for work above the bar, through many >of which one could drive the proverbial tank. > Such as executing code above the bar. But I've wondered before, and seen no comment, whether 31-bit address space constraint is onerous, particularly for LPA. I.e. how often is address space constraint a consideration when deciding what should go in LPA for performance reasons otherwise? >When, for example, the HLASM does not yet support doubleword set-symbol >arithmetic . . . > This has been discussed on ASSEMBLER-LIST; one of the infrequent topics on which you and I agree. At that time an IBM employe defended HLASM; I agree with half his technical arguments. o 64-bit expressions would impel incompatible changes in ASMADATA format. Yes; and I'd be not much satisfied with a compatibliity option. o There would be quiet changes in the results of experession evaluation, possibly incompatible with existing art. Here, I disagree. HLASM responsibly reports as errors overflows in expression evaluation, so any (adverse) effect on assembler behavior would be limited to programers accustomed to ignoring those errors. I don't sympathize with them. (But I do know one instance in base-displacement resolution where HLASM produces results which would be incorrect in AMODE 64. It's so bizarre a case that I doubt any programmers are relying on the behavior. HLASM appears to ignore overflows in base-displacement resolution. I consider this a bug that should be corrected. But I haven't reported it.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
