Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: languages used with commercial software
Message-ID: <12435@smoke.BRL.MIL>
Date: 26 Mar 90 20:44:47 GMT
References: <9003232001.AA00592@apple.com> <12423@smoke.BRL.MIL> <7494@latcs1.oz. <1990Mar25.210033.14719@world.std.com> <7509@latcs1.oz.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes:
>  Compilers don't view the whole program at once.

Neither do assemblers.

>  It seems to me that most programmers ought to be write better code than a
>compiler; ...

Believe it or not, but the issue of relative performance of hand-coded
assembler vs. higher-level language has been the subject of many studies.
Depending on the nature of the problem and on the higher-level language
involved, compiled code can run anywhere from somewhat faster (yes!) to
several times slower.

Because C was developed specifically for systems programming, a skilled
program can write C code that is comparable in run-time efficiency to
hand-coded assembler, for the majority of such applications.  This does
assume that the underlying CPU architecture offers reasonable support
for such higher-level languages; the VAX, MC68000, NS32000, SPARC, etc.
all do, whereas the 65816 doesn't really.  Thus compiled code on an Apple
IIGS typically suffers worse in comparison with assembler than on typical
systems.

However, keep in mind that time spent in making non-bottleneck sections
of code run faster is time wasted.  Even if you're after speed, assembler
should be used for only a small fraction of an application.