GARTHWILSON wrote:
Hopefully it will keep doing passes until all the phase errors are taken care of. Normally two is enough; but I had a situation about 20 years ago where a chain of forward references required dozens of passes. Today's PCs are fast enough that it's not a problem.
It keeps on running passes until the code is stable, yes, though there is a limit to prevent bistable loops running forever.
GARTHWILSON wrote:
Quote:
and I've tried to make it fairly syntax-neutral, so:
Hex can be written as $FE 0xFE, binary as %101010 or 0b10101
Better add FEH and 101010B too.
Good point, though I must admit FEH is horrible to parse as it can appear ambiguous (for instance: A5H and ASH, visually similar, or BAH - is that a label or a value?)
GARTHWILSON wrote:
I'd suggest not requiring labels to start on the margin. Editors with a "condense" mode show, in that mode, only the lines that start with something on the margin, meaning you can make labels of only local interest not show in that mode. If the label is followed by a colon, it also makes it easier to find, as otherwise doing a search for the label may turn up a lot of references to the label before you find the label itself.
Labels don't have to start on the margin, and can end in ':'
GARTHWILSON wrote:
Quote:
Comments start with ;
Yes; but please don't require blank lines to start with a ; as it makes the code look messier. It's good to have COMMENT...END_COMMENT directives so you can have a paragraph of description, and if you want to add or delete something and it changes the line lengths, you don't have to adjust them all by hand again as you would with semicolons.
Blank lines can be blank, comments can start at any location. I can certainly add COMMENT..END_COMMENT, or C-style /** ...*/
GARTHWILSON wrote:
Quote:
I've not (yet) included macro or conditional assembly directives, but would be interested to know which assemblers you all use, preferred syntax and 'must have' features that you use regularly?
The two commercial assemblers I've used for 65xx are 2500AD and Cross-32 (C32 for short), both excellent macro assemblers. I like that C32 doesn't require dots in front of directives. I like that 2500AD allowed different numbers of macro input parameters, and then you could say in essence, "If there's a fourth parameter, do this with it;" and "If there's a fifth one, do the following;". Macros should be nestable, meaning one macro definition can invoke other macros, which in some cases can really shorten the definition.
I've made program flow-control macros which I show in that section of my website, and the assemblers I did it with did not allow assembler variable arrays, so I had to jurry-rig them, to make the structures nestable. It worked fine, but it's definitely not optimum. What I mean by assembler variable
arrays is like EQUates that can be changed as many times as you want—C32 uses the SETL ("SET Label value") directive—but that you can go beyond individual equates and have arrays of them, and index into the arrays.
It is designed to support nestable contexts (ie macros in macros).
A syntax I've seen in other assemblers is that EQUates are constant, but values defined with SET can be redefined at any point by another SET.
I've not looked at a syntax for variables with an array type in an assembler - by that point, I'd usually be switching to C. There's no reason it couldn't be included though if there's a consistent standard.
GARTHWILSON wrote:
If you do everything everyone wants, it can become pretty daunting; so just take the suggestions into account and then do whatever you want or can.
Don't worry - it's a free tool amongst many other free tools, I'm not too worried about pleasing everyone. If your assembler suits your needs, then you have absolutely no incentive to switch.
On the other hand, if you share code and other people want to try it out it's a barrier if they can only assemble it by exactly replicating your tool chain - especially if it only works on a specific platform. My goal is to end up with a tool chain that can be run under a reasonably broad range of browsers (and possibly on the command line with Node), needs no additional installations and can cope with a fair variety of source code.
I appreciate that some people object to Chrome-compatible browsers, but these days Javascript is probably the easiest and most robust way to distribute a cross-platform tool, and once the code base is sufficiently stable ensuring it works with Firefox isn't too much of a challenge.
Login
Register
FAQ
Search
