Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!netcom!rodent
From: rodent@netcom.UUCP (Richard Noah)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Assembler Programming - Costs versus Ben
Message-ID: <18092@netcom.UUCP>
Date: 5 Dec 90 02:41:06 GMT
References: <02129021:20:42GB03@lehigh.bitnet>
Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest}
Lines: 48

GB03@Lehigh writes:

>Programming with an assembler or in machine code is an exercise in
>futility.  Any reasonable compiler will give code that is reasonably
>sized and fast.  Unless you have Knowledge of execution cycles, it is

I didn't see the smiley, so I have to assume you really mean this
(incredible!).  The only conceivable situation under which the above would
be true is if you were writing generic, system- and OS-unspecific
code.  Frankly, a very small percentage of nearly any program consists
of such code.

Example: ever try writing an action game in C?  I did, and was left
wondering why it went (subjectively) 10-20 times slower than the stuff
coming from Europe.  Why?  GETTING CLOSE TO THE MACHINE.  C will let
you get close (being low-level enough) but if you write enough low-
level C you realize you're better of with an Assembler where you have
more control over the specific output.

The same goes for word processors, raytracers, spreadsheets and paint
programs.  There is nothing a high-level language can do that can't
be done faster in Assembly.

> Many personal coding
>techniques do not exploit the potential size saving methods or cycle
>saving techniques.

This has to do with the programmer, NOT the language medium.

>  Thus in general, any compiler will give better code
>than any individual assembler writer.  Also, using a compiler will give

This proves to be not the case when the program has ANYTHING to do with
the hardware or OS, which is most of the time :-)

>better transportablity than assembler.  Finally, the best way to

THIS is the reason high-level languages exist, besides ease of use.
Ease of use and portability, NOT any executable superiority.

>achieve efficiency is to develope a good algorithm.

A good algorithm is independent of the implementation, 'o course.
I love C myself, but don't try to deny the respect and glory that
assembly and assembly programmers deserve.

---------------------------
Ben Discoe, caltech escapee and visionary at large.