Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: languages used with commercial software
Message-ID: <12423@smoke.BRL.MIL>
Date: 23 Mar 90 23:41:06 GMT
References: <9003232001.AA00592@apple.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 43

In article <9003232001.AA00592@apple.com> MMPR004@ECNCDC.BITNET (Scott Hutinger) writes:
>..which leads me to a statement a professor once told me when I told him
>about wanting to take some graduate classes a couple years ago...
>"Nobody writes in assembler anymore..."
>Hmmm, whats his problem?

Perhaps he was trying to do his job and educate you..

There are so many drawbacks to coding in assembler (as compared to a
higher-level language, C in particular) that there are only two reasons
you should do it:

	(1)  For certain operations it may be necessary to work at that
	level.  For example, the provider of the run-time support library
	for the C language must use assembler to implement certain low-
	level operations to support the language.  (That doesn't mean the
	whole system library has to be coded in assembler, just the parts
	that cannot be written in C.)

	Note that this level includes less than is commonly supposed.  In
	particular, device drivers can be written in C (and normally are,
	for UNIX implementations).  Even on the Apple I've written C code
	that efficiently diddles memory-mapped I/O registers, for example
	to control the serial port UART without the overhead of Apple
	slot I/O hooks, toolboxes, etc.  (By the way, this is not
	recommended practice for most commercial code, because it risks
	the program breaking when Apple revises their hardware.  This is
	however independent of the programming language used.)

	(2)  There may be cases where it is essential to squeeze as much
	speed as possible out of a given computer.  This can usually be
	done with the higher-level language, but occasionally it may
	happen that assembler really is necessary.  The cost of using C
	is usually no worse than a 1.3 slowdown over hand-tuned assembler
	(assuming a good architecture, an optimizing compiler, and an
	aware programmer), but on horrible architectures like the 65*
	family the cost is normally worse than that, typically a factor
	of 2 or more.  Usually this is unimportant for typical applications,
	certainly not offsetting the advantages of developing in a higher-
	level language, but in some cases (e.g. some arcade games) it is
	important.  Even so, most likely only a small portion of the
	application constitutes the bottleneck and so only a small portion
	needs special attention (such as recoding in assembler).