A basic assembler is easy to write from scratch, but if you want a compiler too you will need the assembler to deal with standard object files. Things can get long winded and messy like that.
I wouldn't say "easy to write", but this is precisely what I did: a basic-assembly compiler (then extended to macros) and a basic-linker (then extended to linking-scripts), both made from scratch on a lexing library I had wrotten many years before, and at the first step I had to re-invent the .obj format to preserve my sanity because the stuff that exists is too overcomplicated for what I need.
Pros?The C source code of the project looks very friendly and - modesty aside - well written and not with things you never understand, therefore also easy to maintain as single projects and Gentoo Overlays for non-x86 systems.
Which means all-included, all in one project without any external dependency, easily portable, easily testable, and easily fixable if something goes wrong.
ok, maybe I say this because I am the author, and therefore I know well how to do it and therefore where to put my hands... but I really spent a lot of time organizing things well, and immediately, instead of arranging them later, once have already been implemented ...
... this is a defect I see with both gcc and binutils and usually with the GNU stuff... which is always crazy, and every time I have to spend several weeks solving the various problems in cross-compiling gcc, binutils, gdb, and all their dependencies.
Also, the build-up time of my toolchain, from configure to the final binary, is shorter than anything build with GNU physolophy, which is a great point for me!
Cons?Some objtools are missing, gdb "as is" is not compatibile, you don't have an elf file, so firmwares and simulators relying on this form simply won't work, and even gdb (and debuggers based on it) won't work unless you prepare a "bridge" (I did it, I like ... meh ... not so much, but it's there), you have a disassembler, a mapper, which are the two main important tools to have, but you cannot play all the tricks you usually do with the GNU-ld linker scripts and objtools (some of these are passed by gcc when you invoke it with particular flags, again ... this stuff won't work), except a binary to srec and brec dedicated converter that I implemented to manage those two Motorola formats for EPROM programmers.
So, it depends on what you look at
- if I look at the my sources, things keep getting better
- if I look at my Overlay, things have got better more than I couldn't imagine
- if I look at the final ecosystem ... things have got long winded (it took 4 years to the point I described above) and messy as there are a lot of imcompatibilities with existing other tools and stuff.