Quote:
I've used assemblers of one sort or another for over 43 years (6502 assemblers since 1977) and the commercially-developed ones have always been careful to disambiguate things like pseudo-ops, macros and symbols.
I confess I have not investigated thoroughly, but my impression after writing my own assembler is that conventions along those lines - labels must start in column one or must end with a colon, for example - apply to disambiguation only in the sense that it's faster and easier to figure out what a token represents if there's only one way to write it (it also makes the assembler itself easier to write). Whether it makes the user's task easier is a separate consideration, although certainly after working with a particular assembler's conventions long enough, reading source code meant for it becomes "natural".
One reason HXA tries to be a bit accomodating of different conventions is to permit potential converts write in a style that they're used to, rather than force them to learn a whole new set. That's why it accepts numeric literals in any of Motorola or Intel or C formats (eg, '$FF' or '0FFH' or '0xFF'), for instance.
But one can adapt to a new style. I was influenced by the Merlin assemblers, whose pseudo ops are all three characters (sorry, Garth!) and do not use a period prefix. But I've decided I like the period prefix, so for my own code that's what I use. Heck, I stole a lot of things from other assemblers that I decided I liked
Quote:
the unsuspecting programmer could be driven to drink trying to use ASSERT as a symbol, since there is no obvious reason why it shouldn't work.
I would hope not - any attempt to define it as a symbol should generate an error message, and any attempt to use it without defining it should also generate an error message. In fact...
Quote:
This capability is of sufficient importance to me that I would not use an assembler at all that couldn't differentiate between macros and symbols of the same name
Oh, I'm afraid you wouldn't like HXA very much then. Using the same name for two different things seems to me a great source of potential confusion on the part of anyone who doesn't know exactly how such things are resolved by a particular assembler. That the names are in separate tables doesn't matter; that the assembler itself doesn't lose track doesn't matter; what matters is that people aren't nearly as good at it as computers. So when it's possible I explicitly disallow it:
Code:
# verify global name is unique
global function CKgoodname(this) {
# all current callers have done this already
# this = toupper( this )
if ( this !~ SYMglobal ) {
UMerror( "NeedGlb", this )
return( FALSE )
}
if ( SYMexists(this) || PSOPispseudo(this) || \
MACismacro(this) || INSisop(this) || EXPisfunc(this) ) {
UMdupname( this )
return( FALSE )
}
return( TRUE )
}
"People" in this context includes "people who did not write what they are reading", eg., other programmers. Maintainers perhaps, or the merely curious, but in any case people who may not know what the conventions of the assembler used are. They may not have heard of it, or can't find its documentation. Even so, they ought to be afforded a fighting chance of understanding what they're reading.
Alas, then, to use your macro to set up a function call in HXA, you'd have to disambiguate them
Login
Register
FAQ
Search
Most of the use I've seen of octothorpe is in hardware technical literature—as wartung noted, the word tends to be a tongue-tripper.