On Mar 8, 2011, at 08:37, john gilmore wrote: > ... The HLASM can assemble code for AMODE(64) execution, but it can use only > 31-bit arithmetic in the course of doing so. Would that things were > otherwise! > Fully aware that this would require enormous changes to code and data structures and is unlikely to happen (barring a requrement imposed by PL/S), yet I wonder: If HLASM were magically be transformed to use 63-bit evaluation throughout, and truncate to 31 bits where context requires, what incompatibilities would arise? Of course some constructs which now report "overflow" would quietly assemble. I'll ignore this. And I can exhibit one bizarre case where base-displacement resolution succeeds (producing arguably incorrect results) and would fail with 63-bit evaluation.
> About this topic, I do not share Tony Harminc's aversion to the use of > assembly-time set symbols. > Is this traditional, antedating the SETC instruction, or is there some basis in that lookahead processing for SETC differs from that for EQU? > There is a locally famous anecdote about Quine here in Cambridge. He is said > to have waited to see if a speaker used 'data' in the singular or plural. > Hearing it used in the singular, he decamped, secure in the knowledge that > the speaker would have nothing interesting to say. > > Analogously, when I see a piece of assembly language that makes no use of the > macro language, I decamp, secure in the knowledge that it will be of 1) of > little interest and 2) gratuitously long-winded and detail-ridden. > But that was a different thread, best left to languish. -- gil
