🚀 go-pugleaf

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