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=