Ref: Your note of Tue, 17 Oct 2017 10:52:37 -0600 As far as I know, the main problem with ASCII self-defining character constants is that it breaks the existing assembler syntax pattern and would make a mess of what is currently a simple and neat routine.
At present, when the relevant expression parser (for an assembler expression or a SETA expression) encounters a letter (in upper or lower case) as the start of the next term (as a result from TRT) it simply checks whether the next character is a quote and if so goes to the routine which handles attributes and strings, as it is certain to be one or the other (unless it is in error). That's two instructions. In comparison, supporting CA would mess up both this initial selection process and the string-parsing routine. It could for example check whether the first character is an upper or lower case "C" and the next is an upper or lower case "A" (and perhaps "E" if EBCDIC support is required as well for consistency) and the string has at least one more character and that character is a single quote, and if so go to the character string routine. I've long wanted this feature myself, so I'll try to find the time to look at what would be needed to make it work, but no guarantees, of course. Jonathan Scott HLASM team, IBM Hursley, UK Paul Gilmartin wrote: >.... > * There's one place I'm tempted to do this. I can > MVI TARGET,C'[' > > * But this causes a syntax error: > MVI TARGET,CA'[' > * ... because HLASM is too pigheaded to accept C'[' as s > * self-defining term. The rationale given is that this is > * subject to code page ambiguity, Absurd because the code > * for '[' is more stable among ASCII pages than among EBCDIC. > > * So, I could: > MVI TARGET,X'5B' Ugh! > > * Or: (Sigh!) > MVC TARGET(1),=CA'[' > * ... but isn't this subject to the same code page ambiguity? > > * Or: (Sigh!) > MVI TARGET,C'[' > ORG *-3 > DC CA'[' > ORG > > I hate EBCDIC! > > -- gil >
