acmfiu@serss0.fiu.edu (ACMFIU) (05/16/91)
for those of you claiming that *you* can program in assembly faster than in *any* HLL, remember that BASIC is also an HLL. given the *same* libraries as BASIC, does your proposition still hold? (personally i don't believe anyone who says their faster in assembly for the simple fact that HLL was created by assembly programmers ... chicken/egg thing doesn't apply here). albert note: i love assembly. i wouldn't program a IIgs app in anything but assembly.
fadden@cory.Berkeley.EDU (Andy McFadden) (05/17/91)
In article <3579@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: >for those of you claiming that *you* can program in assembly faster than >in *any* HLL, remember that BASIC is also an HLL. given the *same* libraries >as BASIC, does your proposition still hold? Yes, it does. BASIC is interpreted. Compiled BASIC isn't too bad though. > (personally i don't believe anyone >who says their faster in assembly for the simple fact that HLL was created >by assembly programmers ... chicken/egg thing doesn't apply here). Does anybody understand what this means? I think the point is that HLLs are every bit as fast as assembly, which is rarely the case given competent programmers can common compiler technology. If you require a demonstration, I can send you Bresenham's algorithm written in APW C and in assembly. The EXACT SAME algorithm is an order of magnitude faster in assembly. No special libraries; just 65816 code. Why the difference? APW C doesn't try to optimize its output. It uses constructs which work reliably in every case, but are slower than the code I can produce. I can use whichever addressing mode is appropriate for a situation; a compiler has to work very hard to achieve the same results. I can also eliminate redundant loads and stores, I don't have to set or clear the carry before every adc/sbc if I know the previous value, I can keep things in the X and Y registers, etc, etc. All things that a compiler COULD do, if it were sophisticated enough. What a compiler *can't* do is modify the basic algorithm used. Often times, a fair portion of the speed increase from hand-coding a routine in assembly comes from minor modifications of the algorithm, perhaps using special features of an ML. For example, a routine to move data from one region of memory to another might copy it byte by byte; the compiler can't assume that it's just a memory move, so it has to encode the loop. An assembly programmer could just use MVN. You could also do what the FTA did to Bresenham's and expand the loop slightly, which lopped 25% off of the execution time (I had a near-religious experience when I saw their stuff... sigh). To summarize, the people who claim that they can program in assembly faster than in "*any* HLL" have yet to be proven wrong. However, a good compiler can narrow the gap considerably. >albert -- fadden@cory.berkeley.edu (Andy McFadden) ..!ucbvax!cory!fadden fadden@hermes.berkeley.edu (when cory throws up)
rhyde@koufax.ucr.edu (randy hyde) (05/17/91)
I'm not sure I completely understand your comments, but the way I see it, you're claiming that if assembly language programmers limit themselves to using only those features in BASIC, they cannot program any faster in assembly than in BASIC. (I assume you're discussing development time, not run time). If you limit yourself to the features of any HLL, there is little chance you can develop your code faster in assembly than in the HLL. For doing things a particular HLL is well-designed for, it kicks butt on doing the same thing in assembly. If you are going to force restrictions, assembly always loses. People who claim that they can develop code faster in assembly than some HLL (a very elite breed, I might point out) rely on the fact that a single HLL isn't good for everything. Once you leave the paradigm that that particular HLL is good for, developing code becomes as difficult, if not more difficult, than programming in assembly. Good, no expert, assembly language programmers take this into consideration when making their claims. I will say one thing about BASIC: depending, of course, on whose version you're using, BASIC is very limiting. With the exception of FP arithmetic, most good 65816 assembly language programmers with a decent library (see the ANIX.SHK file on ucrmath for a limited example) can crank out a complex program as fast, or faster, than they could in Applesoft BASIC. Yes, there are better BASICs, but there are better machines (e.g., 68000, 32000, etc.) too.
acmfiu@serss0.fiu.edu (ACMFIU) (05/21/91)
In article <13656@pasteur.Berkeley.EDU> fadden@cory.Berkeley.EDU writes: }In article <3579@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: }}for those of you claiming that *you* can program in assembly faster than }}in *any* HLL, remember that BASIC is also an HLL. given the *same* libraries }}as BASIC, does your proposition still hold? } }Yes, it does. BASIC is interpreted. } }Compiled BASIC isn't too bad though. } }} (personally i don't believe anyone }}who says their faster in assembly for the simple fact that HLL was created }}by assembly programmers ... chicken/egg thing doesn't apply here). } }Does anybody understand what this means? regarding my analogy to chicken/egg? well, i just used a very poor analogy. mustn't have known what i was talking about. }I think the point is that HLLs are every bit as fast as assembly, which is }rarely the case given competent programmers can common compiler technology. } }If you require a demonstration, I can send you Bresenham's algorithm written }in APW C and in assembly. The EXACT SAME algorithm is an order of magnitude }faster in assembly. No special libraries; just 65816 code. } }Why the difference? APW C doesn't try to optimize its output. It uses }constructs which work reliably in every case, but are slower than the code }I can produce. I can use whichever addressing mode is appropriate for a }situation; a compiler has to work very hard to achieve the same results. I }can also eliminate redundant loads and stores, I don't have to set or clear }the carry before every adc/sbc if I know the previous value, I can keep }things in the X and Y registers, etc, etc. } }All things that a compiler COULD do, if it were sophisticated enough. } }What a compiler *can't* do is modify the basic algorithm used. Often times, }a fair portion of the speed increase from hand-coding a routine in assembly }comes from minor modifications of the algorithm, perhaps using special }features of an ML. For example, a routine to move data from one region }of memory to another might copy it byte by byte; the compiler can't assume }that it's just a memory move, so it has to encode the loop. An assembly }programmer could just use MVN. } }You could also do what the FTA did to Bresenham's and expand the loop }slightly, which lopped 25% off of the execution time (I had a near-religious }experience when I saw their stuff... sigh). } }To summarize, the people who claim that they can program in assembly faster }than in "*any* HLL" have yet to be proven wrong. However, a good compiler }can narrow the gap considerably. oh, i think you might have misunderstood what i said. when i say "faster in assembly", i don't mean the code will run faster. this will always be the case. what i mean is in terms of someone coding a routine faster in assembly than a HLL, i.e. development time to write the code. }}albert } }-- }fadden@cory.berkeley.edu (Andy McFadden) }..!ucbvax!cory!fadden }fadden@hermes.berkeley.edu (when cory throws up) albert