Because John Ehrman, a languages planner at the IBM Santa Teresa Laboratory, doesn't have SHARE's Assembler Requirements Committee to kick around any more, he has to chair his own session at SHARE to send up some trial balloons. He ran this session at 6:00 pm on Tuesday night, and I expected six or seven people to attend. To my surprise perhaps 20 people showed up, most of whom were not-stupids. Wow!

John introduced each of the following for discussion.

• Diagnostic message for overlapping USINGs: the current version of the High Level Assembler produces an obnoxious message when it detects that an address range is the target of multiple base registers. Is this diagnostic useful? The grudging concensus was that it was, but rarely. Several solutions were suggested, but I didn't like any of them much.
• Changing assembly options at assembly time: some people want to be able to change some of the assembly options through an assembler language pseudo-op. I find the idea somewhat terrifying, and will support the concept only if there is a JCL parm similar to PCONTROL that will absolutely, positively, override any pseudo-op in the program. John Ehrman also mentioned that there was considerable resistance within IBM to implementing any kind of assembly option that changes the code that is generated.
• MNOTEs issued from nested macros are not identified in the assembly listings. You can't tell which macro actually issued a particular diagnostic. John suggested either writing the name of the issuing macro, or providing a mini-trace of calling macros. We liked the last suggestion better.
• Type attributes: in Assembler H, the type attribute of a literal was always "U", or undefined. In High Level Assembler, only the first appearance of the literal is undefined, and the type attribute changes in subsequent uses. One customer asked IBM to change the behavior of High Level Assembler back to the Assembler H way of doing things. We all generally agreed that the customer was guilty of a coding error, and that they should just deal with it.
• Overloading of the apostrophe: John complained that the assembler had a lot of extra work to do when parsing apostrophes out of assembler language code. For example, the type attribute is specified by T' - with no ending quote. He wondered aloud if something should be done about this. While we generally agreed that this was untidy, it was a historical artifact, and inventing new syntax would break a whole lot of stuff.
• Unthread the location counter: should every CSECT start at location zero? There was a surprising amount of support for this notion, because that would solve a number of base register problems. But it would also require that every control section have a private copy of the literal pool.
• Multipliers in numeric literals: one customer has suggested that the High Level Assembler support numerics such as "8M" for 8*1024*1024, and "16K" for 16*1024. We disdainfully dismiss the idea.
• Diddle with dependent USINGs: there was a requirement for support of multiple occurrences of a control block within a common control block. There was general agreement about this.
• New pseudo-op for arbitrary storage alignment: again, there was general agreement.
• Instruction mnemonics: there was lots of discussion about this. IBM occasionally introduces new instructions, which conflict with existing IBM and vendor and customer-supplied macro definitions. How should we deal with this? No solution that was suggested is perfect, but the matter is an important one.
• IEEE floating-point support: this is different from classic S/360 representation, but the world requires interoperability. How to handle?
• SPACE 0: one customer is irritated because sometimes a "SPACE 1" command takes effect immediately after a page eject. The customer complained "The first line should never be a blank line!" So his suggestion was to implement "SPACE 0", which means "put a blank line in the listing unless it's the first line." We reacted pretty badly to this, and Michael Stack commented that the guy shouldn't be killing trees anyway.
• Columnar spacing for XREF: the existing XREF listing is free-form and sometimes hard to read. This was something that we could all agree on, and doesn't seem to be hard to implement.
• Error message eyecatcher: John Ehrman wants to take the "** ERROR **" eyecatcher out of the diagnostics, in order to leave more room on the print line for meaningful data. I asked that some unique eyecatcher be present, so that I can quickly scan for errors using SDSF. One guy insisted that this not be changed, because his installation post-processes assembler printouts. Several of us expressed indignation at this, because High Level Assembler went out of its way to provide facilities that make processing printouts unnecessary.
• Almost all IBM macros assume base register addressability: In a world where relative branch instructions are used, this may no longer be valid. How do we get IBM macros to use relative addressing sometimes... and base/displacement addressing at others?

  ---

  Back to session index
  Back to index of SHARE meetings
  Read the disclaimer