GB03@Lehigh (12/03/90)
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.
rodent@netcom.UUCP (Richard Noah) (12/05/90)
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.
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (12/06/90)
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
dillon@overload.Berkeley.CA.US (Matthew Dillon) (12/07/90)
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