how different assemblers handle labels

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

how different assemblers handle labels

Post by doppelganger »

koitsu wrote: Off-topic-yet-sort-of-not: I spent 2 hours of my time yesterday writing up how 21 different assemblers allow forcing of absolute addressing, and I really don't want to spend several more hours writing up how many different assemblers handle different syntaxes; the term "time vampire" comes to mind. (I will note that in that post, I link to my Assembler Manuals Dropbox directory that has many different manuals. Web-based manuals I do not care to archive/copy. I urge anyone pondering assembler variances or comparisons to take the time to read through what I put there.)
Challenge accepted. I went through the documentation for a bunch of assemblers looking for any rules concerning labels, testing as many of them as I could be bothered to, and this is what I could come up with. I hope somebody finds this useful, and I apologize in advance for any missing or inaccurate information.

Note conventional naming rules for symbols apply (start with letters or underscore, contain letters, numbers or underscores) unless otherwise stated. I will be using the terms 'label' and 'symbol' interchangably, whatever is mentioned applies to both unless otherwise stated.

----------------------------------------

65816 assembler by K.P. Trofatter - Very unusual syntax and documentation lacking any examples of usage. From what I can tell, labels are called links and are created using weird syntax with braces like this: ;{ [+/-][link] } creates a link whose name is specified where [link] is, with + or - optionally associating a direction with it (???), while ;[jump or branch instruction] { [+/-][link]} references it somehow. And no, you're not reading this incorrectly -- the syntax requires a semicolon before every statement, while comments precede the semicolon! Not remotely sure what the author was thinking.

65816 cross assembler by Jeremy Gordon - Labels are limited to 15 characters and are case insensitive. Documentation doesn't mention any other rules concerning labels, but examples show labels on the far left column without colons. Supports local - (hyphen) labels.

ACME crossassembler - Case sensitive. Allows spacing before label definitions (though it does give a warning, which can be suppressed), and ending with a colon is optional. Supports local labels (start with '.') visible with in arbitrarily defined scopes (using the !zone pseudo-op), cheap local labels (start with '@') visible between two global labels, and reverse and forward labels (+/-).

asm6 - Case sensitive. Allows spacing before labels, and the colon is optional. Supports local labels (start with '@') and reverse and forward labels (+/-).

ca65 - Case sensitive by default, but can be configured. By default, allows spacing before label definitions, and requires them to end with a colon. Activating the feature "labels_without_colons" makes colons at the end optional, but requires labels to be on the far left column. Has some other features that allow greater freedom in naming rules ("at_in_identifiers" and "dollar_in_identifiers" allow '@' and '$', respectively, as part of the symbol name except for the first character). Supports local labels (start with '@') and unnamed labels (start with ':'), as well as arbitrary scope definition. Also supports overloading instruction names via the feature "ubitquitous_idents", not a good idea in my opinion, but I digress.

DASM - Case sensitive (tested it with version 2.20.1). Label definitions must start in the far left column, but ending with a colon is optional. Supports local symbols (starts with '.').

fasm - Very terse documentation. I'm just gonna assume given the example "torture.s" included with it, that labels need to be on the far left column, no colon (possibly optional?).

magickit - Supports local symbols (starts with '.'). The colon at the end is optional. No mention in the documentation about case sensitivity or other rules.

merlin 8/16 - Label names are limited to 26 characters in merlin 16 and 13 in merlin 8. Doesn't explicitly state whether anything is case sensitive, but all examples are shown in all-caps, so I'm guessing names are case sensitive. Label definitions are required to start at the far left column. Supports local labels (starts with ':'). Deviates from the conventional naming rules: the only characters not allowed in a label are those less in ASCII value than '0' (0x30), which means ending a label with a colon would actually cause the colon to be part of the label name itself! Only available for the Apple IIc and IIe (128K) and Apple IIGS, which precludes use unless you can be bothered to find an emulator or one of those computers.

merlin 32 - Case sensitive. Same as merlin 8/16, except that local labels can also start with ']' for backwards branching (side node: variables also start with ']' except these are defined as equates).

NESASM3 - Case sensitive. Label definitions must end with a colon or be in the far-left column. Supports local labels (start with '.').

NESHLA - Has some high-level syntax in addition to the instructions. Doesn't explicitly state naming rules, but as it's modelled after the C language, it'd be reasonable to assume they follow convention.

Ophis - Case insensitive. Label definitions must start in the far left column, but they must end with a colon. Deviates slightly from the conventional naming rules: a label that starts with '_' is considered to be local to the arbitrarily defined scope (defined with the .scope directive). Also supports reverse and forward labels (+/-).

ORCA/M - Deviates a bit from the conventional naming rules: a label can also begin with the tilde '~', and underscores in the name are not significant (a label 'FOOBAR' and 'FOO_BAR' are the same to it). Labels can be 1 to 255 characters, must start in the far left column, and are case insensitive. No examples in the documentation use colons at the end of labels. Only available for the Apple IIGS, which precludes use unless you can be bothered to find an emulator or an Apple IIGS.

sasm v1.4 - Not much is made clear on the specific requirements of labels in the documentation, except that the colon at the end is optional. Only available for the Amiga, which precludes use unless you can be bothered to find an emulator or an Amiga.

snasm v1 - Labels can be up to 32 characters long and are case sensitive. Up to 8000 labels may be defined. Somewhat terse documentation, doesn't go into labels much except for examples of suitable names which follows convention, so it's unknown whether or not it requires far-left column placement or a colon at the end.

snesasm v1.0 beta - Very terse documentation. Symbols can be up to 14 characters long, and a maximum of 100 constants and labels (they are counted separately). That's about all the docs says about that. :-P

tricks assembler (trasm) v1.11 - Labels can be up to 18 characters long, supports up to 8192 symbols. Case insensitive. No other specific information about label requirements, unfortunately.

vasm - Case sensitive by default, but can be configured. Varies depending on which syntax and CPU modules it's compiled with, as follows:

Standard syntax: Allows spacing before label definitions. Label definitions must end in a colon. Local labels are supported, either beginning with '.' or ending with '$', but deviate from conventional naming rules, allowing digits only.

Motorola syntax: Label definitions must end with a colon or be in the far-left column. Double colons make a label externally visible. Local labels are supported, either beginning with '.' or ending with '$', but otherwise don't deviate from convention.

MADMAC syntax: Requies label definitions to end with a colon. Double colons make a label externally visible. Equates can be made externally visible by using double equals ("==") in the definition. The vasm documentation states "Labels must not start at the first column, as they are identified by the mandatory terminating colon (:) character", but I couldn't find anything in the original MADMAC assembler docs that places any significance on column 1 as far as regular labels are concerned, so this is a little confusing.

Oldstyle syntax: Label definitions must start at the far left column, but the colon at the end is optional. Local labels are supported, either beginning with '.' or ending with '$', but otherwise don't deviate from convention unlike the standard syntax module.

WDC assembler - Case sensitive by default, but can be configured. Label definitions must end with a colon or be in the far-left column. Deviates slightly from conventional naming rules: a name can also begin and/or contain a tilde ('~') in it. Symbols can be up to 64 characters long. Local labels are supported, either beginning or ending with '?' by default, and this can also be configured with the .LLCHAR directive.

wla-dx - Case sensitive, ending with a colon is optional. Deviates slightly from vonventional naming rules: a label that starts with '_' is considered to be local to the section it was defined in, or the object file if it wasn't defined in a section. Labels that start with '@' are child labels, with additional '@' signifying deeper child levels. Also supports reverse and forward labels (+/-).

x816 - Case insensitive. Allows spacing before label definitions, and ending with a colon is optional. Symbols are limited to 31 characters and can be redefined, and up to 40960 symbols are allowed. Supports reverse and forward labels (+/-).

xa65 - Case sensitive. Allows spacing before label definitions, and ending with a colon is optional. Supports local labels which are in fact the default when using blocks, though globals can still be made beginning with '+'.

--------------------------------

So what can we learn from all of this? Well I don't know about you, kiddies, but I've learned:
a) koitsu is more diligent than I am
b) assembler authors don't know how to document worth a damn, and
c) assembler norms aren't, really, which I guess reiterates the point koitsu already made in his original post.

So I guess it just comes down to finding an assembler that behaves in a way you can tolerate, and get accustomed to it. That's all, have a nice day everyone.
Be whatever the situation demands.
Post Reply