don't click here

What Assembler Do You Use?

Discussion in 'Engineering & Reverse Engineering' started by Quickman, Jan 21, 2010.

  1. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    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.
    1. 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.
    2. 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.
     
  2. Afti

    Afti

    ORIGINAL MACHINE Member
    3,521
    0
    0
    ASM68K, for precisely the opposite reason; I hate working with nameless temporary labels. I'm OCD about label names; even when I work with the AS S2 disassembly, I use named labels.

    Of course, this is more an inefficient quirk of mine than anything else, so I suppose it shouldn't count for much.
     
  3. Spanner

    Spanner

    The Tool Member
    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.
     
  4. TmEE

    TmEE

    Master of OPL3-SA2/3 Tech Member
    1,726
    2
    18
    Estonia, Rapla City
    T-04YBSC-A !
    I keep using SNASM68K, there's no reason for me not to use it, plus is DOS program and runs blindingly fast compared to other things I've tried...
     
  5. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    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.
     
  6. TmEE

    TmEE

    Master of OPL3-SA2/3 Tech Member
    1,726
    2
    18
    Estonia, Rapla City
    T-04YBSC-A !
    AS and ASMX are good options for crossplatformness I guess... ASMX has potential hidden bugs though (Sik stumbled onto one... where is he ?)
     
  7. FraGag

    FraGag

    Tech Member
    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.
     
  8. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    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.
     
  9. FraGag

    FraGag

    Tech Member
    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.
     
  10. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    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.
     
  11. nineko

    nineko

    I am the Holy Cat Tech Member
    6,298
    475
    63
    italy
    Temporary @labels and ++ -- shit confuse the hell out of me. I hate them and I don't see the point of having them. ASM68K all the way, please.
     
  12. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    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.
     
  13. MoDule

    MoDule

    Tech Member
    327
    24
    18
    Procrastinating from writing bug-fix guides
    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.
     
  14. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    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.
     
  15. SegaLoco

    SegaLoco

    W)(at did you say? Banned
    I would personally propose asmx just because that is what I use, and it's portable. I could attempt a decompilation of asm68k assuming you are speaking of the PsyQ product.
     
  16. If you use a 64-bit computer, which in this case I do, I would use ASM68K, because SNASM68K cannot run on 64-bit machines. However, if you use the Hivebrain Disassembly/Assembly, you need to change the code a little to make the transition from SNASM68K to ASM68K. I just did it about an hour ago.
     
  17. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    The disassembly already uses ASM68K.
     
  18. Then, I must be using an older version. Where can I get your latest Sonic 1 Disassembler/Assembler?

    Edit: If this thread cannot move forward with this post. Trash this post so we can continue.
     
  19. SegaLoco

    SegaLoco

    W)(at did you say? Banned
    Heh, man do I take that back now. I try to use snasm68k and asm68k both to assemble now. I also use asmz80 from the psyq set in dosbox. Personally, I would love to see a 1st party sega sdk released, that has snasm68k, snasmz80, the smps sdk stuff, etc... THAT would be awesome for what I am working on right now. I'm trying to write a game using the libraries sega offered to their programmers. =P