On Mar 18, 2013, at 04:37, Binyamin Dissen wrote:
> Wasn't there an IBM warning that user macros should be greater than five
> characters since all opcodes were to be five characters or less, and thus this
> problem would be avoided?
>
Right.
> On Sun, 17 Mar 2013 09:30:34 -0400 Alex Kodat <ako...@rocketsoftware.com>
> wrote:
>
> :>Seems like this might be an excuse to correct what I view as a historical
> :>mistake in the Assembler, namely the precedence of native
> :>instructions/extended mnemomics over macros. ...
> :>
> :>I understand that there might be implementation issues -- I suspect that
> :>the assembler doesn't currently scan all macro libraries and build a
> :>look-aside table of all macros in those libraries, ...
>
Made slightly harder in that:
o SYSLIB may be a mixed concatenation of:
- PDS directories
- PDSE directories
- UNIX directories.
o And DESERV, the obvious tool to use:
- doesn't report members in UNIX directories
- may not be available on VM/CMS
- may not be available on VSE
Isn't there lately a construct that explicitly invokes a macro
rather than an opcode? There should be.
If one first COPYs a macro, it takes precedence over the opcode.
But, ugh!
For the IBM HLASM developer who said the CC masks are easy to
memorize and understand in a listing: That's easy for him to say.
I'll repeat my suggestion of extending the syntax of the opcode
field:
instead of: BNMR etc.
optionally: BR(NM)
Effectively greatly enlarging the name space.
-- gil
