Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <20948@beta.lanl.gov>
Date: 1 Aug 88 21:04:30 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <2960@utastro.UUCP>
Organization: Los Alamos National Laboratory
Lines: 27

In article <2960@utastro.UUCP>, nather@utastro.UUCP (Ed Nather) writes:
> A programmer designs a program based on the tools -- the instruction set
> or the defined, allowable operations in the HLL.  I have seen many cases
> where programming the initial version in C or in (forgive me) Fortran
> leads to a manner of design that precludes an approach that fits the
> underlying hardware better.  It works, but because the HLL does not map
> well into the underlying operations, it can be much less efficient.

I agree with what you say here.  If the high level language you have
doesn't match the underlying machine very well - by all means use
assembler.  As I stated before, one of the major reasons for using
assembler is to use machine features that the HLL doesn't support
(well - or at all).

My previous posting was in response to someone that claimed that
using a better compiler could beat assembly code!  It is obvious
that you can always AT LEAST tie the best compiler you have - just
use the compiler generated code as your starting point for assembly
recoding.

J. Giles

P.S.
    You needn't apologize for using Fortran.  Fortran outperforms
    C on quite a few things.  I certainly use Fortran whenever I
    need to do numerical work.  At least when I want it done quickly,
    correctly, and readably.