🚀 go-pugleaf

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.

In article <02129021:20:42GB03@lehigh.bitnet> 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
>not very advantageous to use assemblers.  Many personal coding
>techniques do not exploit the potential size saving methods or cycle
>saving techniques.  Thus in general, any compiler will give better code
>than any individual assembler writer.  Also, using a compiler will give
>better transportablity than assembler.  Finally, the best way to
>achieve efficiency is to develope a good algorithm.

Newsgroups: comp.sys.amiga.tech
Subject: Re: Assembler Programming - Costs versus Ben
Summary: 
Expires: 
References: <02129021:20:42GB03@lehigh.bitnet>
Sender: 
Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson)
Followup-To: 
Distribution: 
Organization: Jet Propulsion Laboratory, Pasadena, CA
Keywords: 

In article <02129021:20:42GB03@lehigh.bitnet> 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
>not very advantageous to use assemblers.  Many personal coding
>techniques do not exploit the potential size saving methods or cycle
>saving techniques.  Thus in general, any compiler will give better code
>than any individual assembler writer.  Also, using a compiler will give
>better transportablity than assembler.  Finally, the best way to
>achieve efficiency is to develope a good algorithm.

	Where do people come up with this garbage? I don't program the
Amiga is assembly, but I have programmed other makes. Assembly generates
the fastest loops, tightest code, and smallest executable size. 

	As far as the above persons opening statement, "Programming with
an assembler or in machine code is an exercise in futility" - I don't
agree. Saying that work is futile, is an exercise in laziness.

					Jeff

In article <18092@netcom.UUCP> rodent@netcom.UUCP (Richard Noah) writes:
>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
>
>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.

    A lot of people miss a big point ... the fact that in all of these
    programs only a few relatively small routines require 90% of the
    CPU.  THESE routines can be written in assembly.  The REST of the
    program can be written in C.

>>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.

    A couple of other things you are missing...  The reason for
    using a high level language is not only portability, but also
    readability.  I can glance at unknown C source code and figure
    it out it a very short period of time, even if it has no comments.
    I've been programming assembly longer than I have C, yet it may
    take me 10 times as long to figure out an equivalent assembly
    program.  Even stuff I have written becomes foggy, and looking at 3
    year old assembly is generally equivalent to looking at somebody else's
    code for the first time.  Readability translates to fewer errors in
    coding and an easier time spotting errors, as well as a MUCH easier
    time *modifying* an already written algorithm, or tearing it out
    wholesale and replacing it with a better one without having to touch
    surrounding code.

    many of the better algorithms are not necessarily straight forward.  To
    implement such algorithms in assembly invites disaster.  When speed
    is necessary, I code the critical routines -- usually less than 5% of
    the executable, in assembly.  The rest I do in C.

    There even other issues which have not been considered and yet have to
    be pointed out time and time again:  The fact that hardware is ever
    changing, going ever faster.  To take advantage of the faster hardware
    one simply recompiles a C program.	One must REWRITE any assembly
    almost completely from scratch, and if the processor itself changes
    (one goes from, say, a 68030 to an 88000), you are in even worse shape!

    If you intend to write a program and then never touch it again, writing
    it in assembly may work for you.  On the otherhand, if you have greater
    plans for your program (as most people do), writing it in assembly is
    bound to be the source of future problems.

						-Matt

--


    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA