Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Best tools for writing an assembler? Date: Fri, 21 Feb 2014 12:09:53 +0100 Organization: Compilers Central Lines: 69 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-02-027@comp.compilers> References: <14-02-018@comp.compilers> <14-02-025@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1393098087 61970 64.57.183.58 (22 Feb 2014 19:41:27 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 22 Feb 2014 19:41:27 +0000 (UTC) Keywords: assembler Posted-Date: 22 Feb 2014 14:41:27 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1106 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