From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] fast compilers From: Charles Forsyth In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 8 Apr 2003 11:46:35 +0100 Topicbox-Message-UUID: 8c334c70-eacb-11e9-9e20-41e7f4b1d025 i found it far easier and faster doing the powerpc and Fairchild Clipper ports (long gone) using the balance of work in Ken's structure than anything else i've worked with, including my own compilers producing either text or binary. (that's not to say ?[acl] couldn't be improved at all, or made easier to follow and port.) much of the advantage and speed in porting is because only the linker really knows the binary encoding for a particular architecture, which isolates one of the messiest and most tedious parts. (it's a good modular split in my experience.) architectures that have got span- or context-dependent instructions are much easier to handle that way. otherwise, the compiler or assembler--sometimes both!--end up having to duplicate work the linker does or second-guess it. the assembler's trivial (i often do that first to get a good feel for the architecture). with the powerpc it was a little more work because i had to decide what to do about all those peculiar instructions. for a load/store architecture, it's fairly easy to get the C compiler generating reasonable code quickly. on the other hand, i'm glad i didn't need to deal with the non-load/store ones implemented (eg, x86). for most architectures, the linker is an opcode table that drives instruction selection, a small addressing mode classifier, and an assembler that's a big switch statement. i also found it easier to do the linker and produce its input than to have to have the compiler generate correct assembly-language text or to have to deal with typically bizarre and equally ill-documented object and executable file formats. in use, i actually like having all the platforms use the same dataflow syntax and order when i write assembler support. i make fewer mistakes moving between them. one practical nuisance, which can i suppose be underestimated, is that you can't trivially recycle existing assembly-language code (although i've had to deal with several platforms that had several different assembly languages anyway), and it's a challenge given the documentation to work out the mapping for some of the peculiar ones (see powerpc comment above).