Bravo! sas
On Wed, Oct 18, 2017 at 4:19 AM, Jonathan Scott <[email protected]> wrote: > I tried prototyping support for ASCII and EBCDIC (CA and CE) > self-defining constants in Assembler expressions yesterday > evening. The main problem turned out to be that the internal > representation of the text for a self-defining character string > doesn't include the start and end quotes and only has one byte to > save the type character, so I had to change the code to include > the "A" or "E" type extension and the leading quote as part of > the value, which then required special-case logic to suppress the > leading quote at the various places where the value is > substituted back into text. At present, I have not attempted to > implement the Unicode type CU for self-defining constants. > > The CA type is translated to ASCII using the same table as is > used to translate ASCII DC values, which is currently a fixed > table that maps a subset of code page 37 to 7-bit printable > ASCII, leaving unchanged any codes that do not map to ASCII. > The CE type defines a value which is not translated even when the > TRANSLATE option and COMPAT(TRANSDT) are in effect, as for the > corresponding type on DC. > > Here's some sample output from a test: > > 000000 00000 00030 1 TESTASDT CSECT , > 000000 92F0 1000 00000 2 MVI 0(1),C'0' > 000004 9230 1000 00000 3 MVI 0(1),CA'0' > 000008 A512 F0F1 0F0F1 4 IILH 1,C'01' > 00000C A512 3031 03031 5 IILH 1,CA'01' > 000010 A512 F0F1 0F0F1 6 IILH 1,C'01' > 000014 A512 F0F1 0F0F1 7 IILH 1,CE'01' > 000018 92BA 1000 00000 8 MVI 0(1),C'[' > 00001C 925B 1000 00000 9 MVI 0(1),CA'[' > 000020 A512 BABB 0BABB 10 IILH 1,C'[]' > 000024 A512 5B5D 05B5D 11 IILH 1,CA'[]' > 000028 A512 BABB 0BABB 12 IILH 1,C'[]' > 00002C A512 BABB 0BABB 13 IILH 1,CE'[]' > 00030 14 ASCII_0 EQU CA'0' > 00031 15 ASCII_1 EQU 1+CA'0' > 16 END , > > The changes (about 60 lines of code plus various comments) are so > far only a prototype, with minimal testing, but I think I've > proved that support is feasible, so there's a good chance we may > be able to make that support available soon for Assembler > expressions. For consistency this syntax should also be > supported in SETA expressions but I haven't yet had time to look > at that. And of course it all needs documentation updates. > > Square brackets are another problem, as usual. The square > brackets in the test were in code page 37 (hex BA and BB) which > does not display correctly here in the UK (where they are hex B1 > and BB). We normally use code page 1047 for product code anyway, > where square brackets are hex AD and BD as in TEXT code pages and > the C/370 compiler. I think that the ASCII translation should > probably use 819 rather than 7-bit ASCII as the target code page, > and should be made sensitive to the existing CODEPAGE option, > which currently only affects Unicode. Also, the CODEPAGE option > should be extended to cover a wider range, including 1047. > > Jonathan Scott > HLASM team, IBM Hursley, UK -- sas
