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: "BartC" Newsgroups: comp.compilers Subject: Re: Best tools for writing an assembler? Date: Sat, 22 Feb 2014 00:28:19 -0000 Organization: virginmedia.com Lines: 34 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-02-028@comp.compilers> References: <14-02-018@comp.compilers> <14-02-021@comp.compilers> <14-02-023@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1393098120 62287 64.57.183.58 (22 Feb 2014 19:42:00 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 22 Feb 2014 19:42:00 +0000 (UTC) Keywords: assembler Posted-Date: 22 Feb 2014 14:42:00 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:1107 "Robert A Duff" wrote in message > Ivan Godard writes: > >>...we use the C++ compiler as the first pass, then execute the resulting >> program as the second pass. You write a C++ function for each machine >> operation: "add(regNum r1, regNum r2)" or whatever. > > Good idea, except I'd write it in Ada or OCaml or something. I've > done something similar. > > You can do all sorts of powerful things this way, because you have the > full power of C++ (or whatever) at your fingertips. > > And if you want to write a compiler for some higher-level language, it > can call those same "add" routines. I've never liked the compiler > design that has the compiler generate assembly language as text, and > then feed that text to a traditional assembler (even though I've > written such compilers). It seems needlessly inefficient. I've gone the other way, from generating machine code (or my own object code) directly, to now generating assembly source code. Then I can leave all that side of it to (in my case) NASM, to worry about object and executable file formats, and instruction encodings. The inefficiency is not really an issue any more (for inefficient and bloated text files try HTML and XML). If the resulting code was not needed for a standalone executable or for libraries, then maybe a function-based scheme could work well, although to examine the output, you might still want a familiar assembly-like text format. -- Bartc