Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!dg!Publius
From: Publius@dg.dg.com (Publius)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <628@dg.dg.com>
Date: 11 Jul 90 20:49:05 GMT
References: <40052@mips.mips.COM>
Reply-To: publius@dg-pag.webo.dg.com (Publius)
Organization: Data General, Westboro, MA.
Lines: 52

In article <40052@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>Generalizations: the following factors will encourage one to use
>assembly code (left) or compiled code (right).  I think most of the
>anecdotes so far fit at least one of these.  The interesting questions are:
>1) Are there more good genralizations?
>2) What kind of experiments can be done to quantify these more specifically?
>ASSEMBLER			COMPILER
>1. Old, non-optimizing compiler	Modern, global optimizer, at least
>				In scientific world, vectorizer/parallizer
>					if appropriate.
>2. Architecture/language mismatch	Architecture/language well matched
>	2a. Architecture weird
>	2b. Language not expressive enough
>3. One architecture target, forever	Portability
>	(as in some embedded)	(as in UNIX commands)
>4. Absolute speed requirement	Premium on development cost, maintenance
>5. Absolute space requirement	Space costs, but no hard, low limit
>6. Programming time is cheap	Programming time is not cheap


These are fair-minded, gentlemanly, brilliant comments.  I only want to add
the following:

Many "large" programs spend most of the CPU time in one or a few relatively
"tiny" routines.  Hand-coding these routines will not cause much maintenance
and portability problem, AS LONG AS they can be isolated.

I am not sure if the "comp.arch" is the proper place to talk about software
development methodology.  However, it is not unusual these days that
different pieces of a large-scale software project are written in different
languages.   If we take a look of the complex source tree of a typical
large-scale software, with many level of makefiles, quite often we will
run into an "asm" sub-directory, in which we can find a few ".s" files.
The key is not really if the assembler code can be used.  The key is if
these assembler-coded routines can be properly isolated and documented.

Many of the optimization problems belong to the "NP-complete" or even
the "Turing-uncomputable" categories.  Thus, no matter how smart the
global optimizer is, as long as it is equivalent to a Turing machine,
it can not achieve the FULL optimization for EVERY situation.

If a large program spends most of the CPU time in a tiny routine, then,
go ahead and hand-code it in assembler and do an exhaustive optimization,
as long as you isolate it and document it comprehensively.



-- 
Disclaimer: I speak (and write) only for myself, not my employer.

Publius     "Old federalists never die, they simply change their names."
publius@dg-pag.webo.dg.com