Post by bartc Post by bartc
It's silly really because it can be literally a one-line change in a
compiler to allow $.
What platform are you using that needs this?
I've seen plenty of assemblers that use $ as a name for the current
location counter. Most of these parse $ as a single-character
token, so anything like aaa$bbb will be a syntax error, for the
same reason that three consecutive identifiers like aaa bbb ccc
would be a syntax error. It is possible to allow symbols containing
$ in these assemblers without parsing ambiguity. This may require
substantial code changes.
There are also plenty of assemblers that use $ as a prefix for a
machine instruction operand, sometimes to indicate that it is an
immediate operand (rather than a memory reference). Others use $
as a prefix for a constant to indicate that it is in hexadecimal.
This can be compatible with the use of $ in identifiers if an
indentifier is prohibited from *BEGINNING* with a $. Is that
acceptable for the OP's intended usage?
Post by bartc
Let me reiterate, in either a compiler /or/ assembler, support for $ can
That's unlikely. For one thing, a C compiler needs two different
character classes, one for the characters that can *BEGIN* an
identifier, and one for the characters after the first in an
identifier (digits are part of the second class but not the first).
It is probably more efficient for a compiler to use the C locale
and <ctype.h> functions. Or, if they're allowing all the characters
in Unicode (Unicode has properties "ID_Start" and "ID_Continue" for
this, and they seem to apply to all of a random sampling of Egyptian
Hieroglyphics), that would probably involve a switch with over 10,000
Post by bartc
In the rare case of a compiler working with an existing assembler that
doesn't support '$' (or any other character, eg. Unicode), then it will
need to devise some escape mechanism. Not take it out on the user by
saying you can't do this because there might be the odd assembler out
there that can't handle it.
Definition: system linker - the linker for a platform that is the first
one in this list, if there is one at all:
(a) The linker that ships with the system.
(b) The linker from an add-on development package that is distributed by
the same vendor as the system.
(c) The most-used linker for the platform if neither (a) nor (b) are available.
(d) There may not even BE a system linker.
If there is a system linker, it's generally very desirable that you be
compatible with it. If there is no system linker, then chances are your
implementation will become one, and you don't have to worry about backward
compatability with anything but older versions of your code.
IMHO, a compiler for a platform should not accept $ in identifiers
by default if the system linker won't accept them and it doesn't
ship with a linker that accepts those identifiers. In other words,
don't confuse the user with vague linker errors when the compiler
should have caught the error earlier and there *ISN'T* a linker (or
escape mechanism) that will work.
Devising an escape mechanism that is an extension, not an incompatible
change, may not be easy (or even possible, given compatability
requirements). If there's an existing escape mechanism, great,
extend it. URL-encoding may come to mind if the system linker
accepts symbols with a % in it, but it may be impossible to stay
compatible with the system linker and your linker with arbitrary
use of % permitted and pre-existing. If the system linker generates
'foo%' and yours generates 'foo%25', they won't match up. The
system linker's 'foo%25' may incorrectly match your 'foo%' (which
escaped is 'foo%25') and mess up with a bogus duplicate symbol
Assemblers are also likely to have all sorts of other reserved
identifiers, such as opcode names, register names, pseudo-op names,
etc. In the past this was dealt with by prefixing all C identifiers
Incidentally, in C, the backquote is already taken for BCD constants,
although that usage was pretty obsolete even in 1978.
@ may be reserved in assembly language as a prefix for register names.