Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!uflorida!kluge!serss0!acmfiu
From: acmfiu@serss0.fiu.edu (ACMFIU)
Newsgroups: comp.sys.apple2
Subject: Re: programming in assembly faster than HLL
Message-ID: <3604@kluge.fiu.edu>
Date: 21 May 91 08:35:30 GMT
References: <3579@kluge.fiu.edu> <13656@pasteur.Berkeley.EDU>
Sender: news@kluge.fiu.edu
Organization: Florida International University, Miami
Lines: 65

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