Xref: utzoo comp.lang.c++:2182 comp.lang.c:14502 comp.lang.forth:715 comp.lang.fortran:1586 comp.lang.misc:2272 Path: utzoo!utgpu!watmath!clyde!att!poseidon!ech From: ech@poseidon.ATT.COM (Edward C Horvath) Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc Subject: Re: Assembly or .... Message-ID: <609@poseidon.ATT.COM> Date: 3 Dec 88 05:32:08 GMT References: <1432@zen.co.uk> Organization: AT&T Bell Laboratories, Lincroft, NJ Lines: 23 In article <1961@crete.cs.glasgow.ac.uk> (Fraser Orr) writes: >I don't agree that there is ever any necessity to code in assembler. We >have languages that produce code just as good as hand crafted assembler >(such as C), so why not use them for this sort of thing. From article <1432@zen.co.uk>, by frank@zen.co.uk (Frank Wales): > Suppose you don't have a compiler. Or an assembler. Suppose you're writing > these for a brand new processor -- what do you write them in? I have to disagree with Mr. Orr, but not for the reason Mr. Wales cites. Most assemblers are table-driven, as are the code generators for typical compilers. So you "teach" those programs about the new machine, compile to get a cross-system, and compile again to get a "native" system. My fingers never leave my hands... Assembler remains useful where nothing else will do, in performance-critical operations (it's amazing how slow hashing is in C compared with assembler) and nasty realities like dealing with MMUs, I/O devices, and other ugly bits of hardware that have ugly timing constraints. I have no fear of assembler, but I only use it AFTER I run the performance measurements (or when that ugly hardware is an issue). =Ned Horvath=