Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!sri-unix!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.misc
Subject: Re: Assembly Language
Message-ID: <4842@jade.BERKELEY.EDU>
Date: Fri, 21-Aug-87 19:50:29 EDT
Article-I.D.: jade.4842
Posted: Fri Aug 21 19:50:29 1987
Date-Received: Sun, 23-Aug-87 11:33:21 EDT
References: <892@edge.UUCP> <1305@faline.bellcore.com>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 44

In article <1305@faline.bellcore.com> gtchen@faline.UUCP (George T. Chen) writes:
<For that matter, any program done in any HLL can be done in assembly
<and made to run as fast if not faster. 

Of *course* it can be made to run as fast. Just tell your compiler to
give you the assembler source listings, and viola, you've got an
assembler program that runs as fast as the HLL version. Who cares.

As for making it faster, the statement "almost any program done in any
HLL can be done in assembly and made to run faster" is true. Then
again, so is the even more general "almost any program can be made to
run faster." A different special case of this is "almost any program
done in assembler can be made to run faster in an HLL."

One way to make an HLL program run faster is to let the compiler turn
it into assembler, then hand-tune the assembler. On the other hand,
one way to make an assembly program run faster is to translate it to
an HLL, then tune the algorithms - or better yet, choose a faster one.
I am aware of examples of both.

But "run faster" or "be smaller" isn't the right question. The right
question is "is it fast/small enough now?" If your interpreted LISP is
fast enough for the application, then it's fast enough, and you don't
need to spend more time on it. If it isn't, then you work on making it
faster - compiling it, translating critical sections to assembler,
etc. On the other hand, if your carefully hand-crafted assembler isn't
fast enough, then you've got to do something to make it faster.

Finally, speed isn't the only criterion. Time to market, competition,
portability, availability, familiarity, etc. are all important. If
you're trying to squeeze something onto a processer+ram chip,
assembler may be the only rational choice. If you're writing for a
large Burroughs box, you may not *have* an assembler.

This is why it pays for a programmer to be familiar with many
languages (and other tools): it gives them a better ability to choose
the right tool for the job at hand.

	<mike
--
Must have walked those streets for hours,		Mike Meyer
In the dark and in the cold,				mwm@berkeley.edu
Before I really could accept,				ucbvax!mwm
There's no place called hope road.			mwm@ucbjade.BITNET