> A less 'easy' alternative would be to introduce types, and > associated instructions: GBLA32, GBLA64
Initial reaction: Ugh! > Or, a PARM option to select 64-bit capability. That would most readily > support ASMADATA compatibility. Exactly what I meant. Ideally two parms: allow 64-bit symbols and write new ASMADATA format. It would be permissible to select 64-bit symbols with old ASMADATA, resulting in a warning that some values in ASMADATA might be truncated. Default to old format, with a documentation notice that in the next release it would start defaulting to new format. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, July 05, 2014 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HLASM doubleword set-symbol arithmetic On Sat, 5 Jul 2014 06:10:29 -0400, John Gilmore wrote: >There is---I do not write with any inside knowledge---some prospect >that Paul Gilmartin will not need to confront another option. A >fairly obvious and 'easy' design option is that of making all >arithmetic set-symbol values signed doubleword ones, and if I were >laying bets it is the one I should bet that the IBM group in Hursley >would choose. > That's the design option I'd choose. And, I'd hope for64-bit support not ony for SETA but also for EQU. A less 'easy' alternative would be to introduce types, and associated instructions: GBLA32, GBLA64, SETA32, SETA64, EQU32, EQU64, ... with the legacy forms equivalent to the -32 forms. And rules for mixing types in expressions, and BIFs for conversion. Or, a PARM option to select 64-bit capability. That would most readily support ASMADATA compatibility. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
