Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Best tools for writing an assembler? Date: Mon, 24 Feb 2014 20:35:01 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 44 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-02-032@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-15 Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1393277735 85432 64.57.183.58 (24 Feb 2014 21:35:35 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 24 Feb 2014 21:35:35 +0000 (UTC) Keywords: assembler, history, comment Posted-Date: 24 Feb 2014 16:35:35 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:1111 Patrik Tzri wrote: > 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. > 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] Some years ago, I used a system to assemble 8080, 6800, or 6809 code using the OS/360 assembler. Each instruction is a macro, though many call other macros to generate the appropriate addressing mode. Once you get the addressing modes right, the rest are very easy to write, mostly putting in the appropriate opcode and calling the one to do the right address mode. In addition, there was a program to generate motorola hex files from OS/360 object files, and another to fix up the lising file. The usual OS/360 assembler listing file has the generated code to the left of each instruction. For a macro, you only see that if you have the macro expansion shown. The fix-up program moves it up such that it is to the left of the macro call, and then doesn't show the macro expansion (all DC instructions). It uses assembler arithmetic to generate little endian addresses on a big endian system, using one byte (AL1) address constants. Some of the assembler contentions remain, though, such as constants still being in OS/360 format (X'1234') instead of the more traditional intel form (01234H). I do remember taking some existing source and, with just a little editing, getting it to assemble. Also, the comment and label conventions will be those for the OS/360 assembler, but that wasn't much of a problem. (As I remember, the intel assembler uses a colon after a label, and the OS/360 assembler doesn't want one there.) It is very convenient in that the host assembler does all the keeping track of forward references. -- glen [This is a classic and very useful hack. The assembler for at least one of IBM's minis, maybe the System 7, worked that way. -John]