Re: Best tools for writing an assembler?

Patrik Tzri schrieb:
> Thank you all.
> About using an existing assembler -- it's like writing Machine Description
> files for GCC right? Well my problem is that those stuff seemed quite complex
> and would take a while to understand all syntax and options, and then define
> all 'generalized' instructions.


Depending on your instruction set and addressing modes, it may be
simpler and more instructive to write your own assembler. During this
discussion I remembered that I wrote my first assemblers (and
disassemblers) in Forth, for all the microprocessor development
systems I had built for the then available 8 bit microprocessors. At
least Forth uses an interesting and amazingly simple approach to
generate machine code. Plus it comes with a full development system,
includes macro capabilities off the shelf, and many more goodies.


Unfortunately Forth writes the generated code directly into RAM, which
is nice for immediate debugging of the source code, or for an JIT
assembler/compiler, but nowadays assembler output most probably should
go into object files. In so far I'd suggest to use some existing
assembler, capable of writing the required object file format, and add
your instruction set to it as just another front-end. Essentially the
same as John suggests:


> Any good "Getting Started" guide on that with any assembler or compiler which
> would make it easier to learn?
> [Adapting an assembler is much easier than retargeting a compiler.
> The assembler doesn't know anything about the semantics of
> instructions, just what field goes where. -John]


This said, I cannot resist to add some more comments on the items
popping up during this discussion.


IMO the choice of the implementation language of an assembler is
unrestricted, OO capabilities are not required (but nice to have, of
course).


IMO an automated parser is overkill for an assembly language, it may
take more time to develop and debug the parser than writing one by hand.
Here it matters whether compatibility with an existing assembly language
is required, in this case a parser generator may be helpful. But when
one is free in the construction of the language, it may be a good idea
to cast your own language, easy to write/read/understand, and easy to
parse. In detail for CISC (Intel) processors I preferred to use the
Motorola assembler notation, with an operand size (.b,.w ...) appended
to the opcode, and prefixes for hex/octal/binary numbers. When you
compare the 32 bit x86 (Intel) and 64 bit (AMD?) x64 assembler
languages, you better know what I mean.


Instead it's essential to understand the philosophy behind the target
machine architecture, in order to create a table of instruction
mnemonics, opcodes and allowed operands and addressing modes. Assembling
one instruction then boils down to:
1) which instruction to encode?
2) get the operands
3) determine the best opcode for that combination, if there is a choice
4) merge the bits for these parts, checking for invalid combinations


Also the object file format deserves some studies, in detail the
possible fixups for external symbols. Every use of an external symbol
restricts the encoding of that operand, to a form that the linker or
program loader can process later. Also the debugger should be
considered, so that the symbol tables for the debugger can be generated.


Last not least an assembler should allow for kind of macros, for target
specific items like calling conventions, register preservation, and
other subroutine entry/exit code.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.