What Assembler Do You Use?
or: A tale of two^H^H^H^H three assemblers

At the moment three different assemblers seem to be in use by different people for different purposes. There's some crufty old stuff using SNASM68K which I think we can leave where it is, Hivebrain's Sonic 1 disassembly uses ASM68K and Xenowhirl's Sonic 2 disassembly uses AS.

I think it'd be beneficial to us as a community to standardise on one assembler for all our work, and now that we have the Community SVN Project we can look to achieve lofty goals like this which before would merely have been a pipedream.

If all the disassemblies use the same assembler, a hypothetical user porting code doesn't have to worry about whether his assembler will look down its nose at him for having more than twenty data items in a single dc pseudoinstruction or whatever.

With only one assembler in use we can be fully cognizant of those of its idiosyncracies which affect us and incorporate workarounds in the code everywhere they matter, rather than having a different set of workarounds in every disassembly.

The question of course remains, which one? That's what I'd like to open the floor to in this thread. I'm going to put my vote in for AS because I am madly in love with nameless temporary labels.

I use ASM68K on my non-Sonic 2 stuff. However, I would find that using AS would be beneficial due to the features it has (such as the tempoary labels) as well as it being cross-platform. Perhaps one day the Sonic 1 SVN disassembly should be converted, since there's a AS version of the 2005 disasm by shobiz on the wiki.

However, I'm still sticking to old disassemblies due to the new S1 disassembly not referencing old labels and the new Sonic 2 disasm confuses the hell out of me with its new equates.

The cross-platform thing was actually something I was considering without even realising it.

I'm not saying thou shalt use AS for everything thou dost, you can use SNASM68K if you like it for your own work. For stuff intended for use by other people, I suggest standardising on a single assembler, be it ASM68K, AS, whatever.

I've asked myself this very question a few times, and although I can see advantages and disadvantages to each of the 3 assemblers we currently use for our disassemblies, I decided to take my own route and work on my own assembler, taking my favourite features from ASM68K and AS without the annoying stuff, while also adding features I feel are missing and would make it easier to develop a new game from an existing base. For example, I posted a long guide with several steps explaining how to add a level slot for Sonic 1; with my assembler and what I am planning to implement in it, it would be a matter of a few lines, all in the same area, not scattered all across the disassembly.

Of course, to take full advantage of my assembler's new features, new disassemblies would have to be prepared, but it would just be the perfect occasion to standardize our tools and naming conventions so that we can port stuff from one game to another with a simple copy and paste operation. Are you going to blame me for preferring lazy work to error-prone work? (I'm a programmer, so you can't.) I was also planning on making a disassembler targeting my assembler (with an option to make "generic" code that most assemblers should accept as is or with minor modifications), with a focus on making a disassembly that assembles to a bit-perfect version of the original ROM (which is not always the case with disassemblies generated by IDA Pro, I have heard).

However, some people will complain that those features are too far away from "normal" assembly programming. I came up with a simple solution: make a version suitable for hacking and making new games, and a version suitable for research, where e.g. the raw RAM addresses are written instead of being inferred by the assembler, as is currently the case with the SVN version of the S2 disassembly. The research version could easily be generated from the hacking version, so it would not be duplicated work. And if you want to make a hack but don't like the "higher-level" features, you are, in my opinion, going to miss out on an opportunity to streamline your work.

I'm working on this with the intention of making a hack myself, and I find that the tools we currently have do not cover some special cases, like mappings that reference frames from another mappings set (e.g. Map_obj3A and Map_obj7E in S1, which shares some frames with Map_obj34, making them hard to use with SonMapEd). I'm building my assembler as a library (DLL on Windows), so that applications can use the metadata generated by the assembler, making them effectively work with the code rather than with the data. I'm also working on an application (called Megadev) that will host plug-ins that will be able to work with the source code, making them more flexible and more powerful, without sacrificing usability. Oh, and all of this will be cross-platform, as I am using Qt for Megadev and the assembler is programmed in C. The disassembler mentioned above would also be a plug-in for Megadev.

As great as it may sound (to me at least, but course I'm biased towards my own work), it's a massive amount of work, and I'm afraid that nobody will be interested and that I'll have worked for nothing. I think it sounds promising; some may find it disgusting, especially if you don't like how the S2 SVN disassembly is set up. I started working on my assembler late 2008, and it can't even assemble more than RTS yet (and this was only to test if labels would get assigned the correct value). I'm trying to spread my work over the different subprojects to keep my interest and to be able to release everything at once, because some of the stuff is not as useful as it would be without the other stuff. I'm also using the knowledge I've accumulated over the years to make my software good from the start, I.e. it's not a dirty hack job that will have to be started over because it became unmaintainable.

If you guys are interested, I would like to know. It could completely change our way of hacking and developing games for the Mega Drive/Genesis. Don't expect anything soon, as it's not even half-way done, but it's not a new-born project either and I don't want to just abandon it after all the time and efforts spent on it.

I don't see the point of nameless labels at all. They're difficult to follow and seem to defeat the point of having a fully labelled/commented disassembly.

I wouldn't mind switching to AS (or another assembler) if it has all the functions I need. I vaguely recall there being a couple of things I've used in S1 that aren't supported by AS, but I can't remember what they are.

To me, using nameless symbols is akin to using structured programming (for, while, do, if/else) instead of goto's in C. Finding a good name for a symbol can be hard, and choosing a bad name can be misleading. When I work on Sonic 1 with ASM68K (which I don't have much time to do anyway), I'll use @skip when I would have used + with AS. When you're skipping 2 instructions, if those instructions are self-explanatory, and if the condition check itself is also self-explanatory, adding a significant label won't really improve readability. They are to be used on a short scale; a loop that spans 100 lines would be easier to understand with a descriptive name than with a -. I tended to abuse them when I was working on the SVN version of the Sonic 2 disassembly, and I reverted some extreme cases where it was difficult to even understand the syntax.

To me, using nameless symbols is akin to using structured programming (for, while, do, if/else) instead of goto's in C. Finding a good name for a symbol can be hard, and choosing a bad name can be misleading. When I work on Sonic 1 with ASM68K (which I don't have much time to do anyway), I'll use @skip when I would have used + with AS. When you're skipping 2 instructions, if those instructions are self-explanatory, and if the condition check itself is also self-explanatory, adding a significant label won't really improve readability. They are to be used on a short scale; a loop that spans 100 lines would be easier to understand with a descriptive name than with a -. I tended to abuse them when I was working on the SVN version of the Sonic 2 disassembly, and I reverted some extreme cases where it was difficult to even understand the syntax.

This is a minor dilemma with disassembling things; good thing for loc_xxxx.

As for me, I use either asm68k or asmx only because they're the only two I'm accustomed to. asmx is okay but needs to be fixed ... you have to specify the -e option or else it won't report errors? seriously? The Sonic & Knuckles disassembly won't work with asmx either, so derp.

It's about not polluting the label namespace. A permanent label is supposed to be a major division of the source code; the rts at the end of a routine which gets conditionally branched to half a dozen times but never used outside the routine itself definitely doesn't deserve a label of its own - it's not that important.

Nameless labels are for short self-explanatory loops - it's obvious that a dbf instruction creates a loop, using a @loop temporary label for it is wasteful - the eye doesn't need to be drawn so strongly to the destination of that loop. dbf d0,- saves typing.

It might be worthwhile to construct an online viewer for assembly which will provide nice readable arrows instead of ++ -- for those people who have difficulty following them.

I'm with FraGag on this all the way.I love nameless symbols, since I don't have to think of a name for every measly little branch. ++ and -- are A-OK with me as long as I can see on-screen where they point to.

Of note: I updated the Hivebrain Sonic 1 disassembly which had been modified to target AS so it produces a byte-perfect copy of the original ROM by adding the macro from the Xenowhirl Sonic 2 disassembly which fixes the 0-displacement optimisation.