From: scott@mcl.mcl.ucsb.edu (Scott Bronson)
Newsgroups: comp.sys.mac.misc
Subject: Re: WriteNow 3.0 and assembly language
Date: 16 Apr 92 18:45:30 GMT

In <5457.29e9a04e@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:

>In article <scott.702673933@mcl>, scott@mcl.mcl.ucsb.edu (Scott Bronson) writes:
>> There is one solid fact that was muddied in the above paragraph.  Assembly
>> will *always* run at least as fast as the high level language.  Usually
>> if you use the same alogrithm as the HLL, assembly will run around twice
>> as fast, simply because you don't perform all the redundant operations.

>WRONG! You didn't read my original posting very closely, did you? The fact was,
>spending 2 weeks re-writing the original program with improved algorithms in
>a high-level language was MORE beneficial than spending 2 weeks writing the
>original in assembly. Indeed, by the time the improved high-level version
>was completed, there was NO LONGER ANY NEED for assembly.

How much programming experience have you had??  I said that assembly
will always run at least as fast" and you retort WRONG!?  The Macintosh
does not use a CPU that interprets a high level language, so assembly
WILL ALWAYS RUN AT LEAST AS FAST.  I really don't think I can explain it
any better than that.

Perhaps in VERY SPECIFIC cases, re-writing the algorithms in a high
level language will give benefit.  However, I'll make you a bet of
any monetary value that I can write a polygon fill in five hours
that will outrun any algorithm that you write in a high level language.
I'll even give you two weeks to tune it to the absolute maximum speed
that the high level language can muster.  My assembly algorithm that
I take five hours and write will blow yours away.  It's that simple.
Different languages for different solutions.  You cannot just blanket
an answer the way you are trying to.


>> The 680x0 was designed for the assembly language programmer.  It's assembly
>> is among the cleanest for humans to write, but not so friendly for compilers.

>I find this a complete contradiction. What is easy for humans must be easy
>for compilers, because the compilers are written by humans.

You've never written a compiler, have you?  Go write any high-level
compiler then see if you still feel this way.

it is trivially easy for you to read a wedding invitation that uses the
traditional, sweeping fonts.  I dare you to find a computer that can
OCR the very same invitation.  You can look at a dithered photo in a
magazine and recognize instantly that it's a picture of Half Dome
(or whatever).  Now find a computer that can analyze that image and
tell you it's in Yosemite.  If you muddied the image with a bit of
noise, you could still tell in a split-second that it's Half Dome.
I haven't heard of a computer that could do the same.


>> Thus, I find that coding up to 40% of your program in assembly is not
>> unrealistic and doesn't add too much time do the development process.  It
>> does cut drastically (for me) from the debugging process, because you know
>> once a routine is wired, it is *wired*.  You just don't have the control
>> over a high level language to achieve this confidence.

>Perhaps this works on one-man projects for your own use. This won't cut it
>in the "real world" where several people are working on the same code. If
>anything, I've found assembly code to be MORE error-prone than high-level
>language code. 

Perhaps you're just not using good style.  If you spend a week to get
"in tune" with the idiosyncracies of assembly, you'll be able to write
code as easily as you would C.  Document everything, and write it in
top-down modular style.  It's no harder to collaborate on a well-managed
assembly project with good assembly programmers than it is to collaborate
on a similarly managed C project.

Incidentally, i've found APL to be MORE error-prone than assembly, and
APL is a high level language.  Again, you can't just blanket a single
answer on top of a complex problem.


>> This is a good point, though.  It's easy to lose sight of this.  The
>> algorithm means so much more than the language it is compiled in.

>And re-coding algorithms is tons easier in a high-level language than in
>assembly. QED.

NOT!  Listen, the solution depends on the problem.  Go write a good
object-level debugger without using a drop of assembly.  Then start
over and code the parts that need it in assembly.  Note that I said
parts of it.  You'll end up with a debugger that runs 50% faster and
was developed in 80% of the time.  If you're a good assembly language
programmer, that is.  You can't just blanket simple answers on top
of complex problems like this.  It doesn't work.

I don't think you feel very comfortable programming in assembly language.
How about you spend a week getting fluent in assembly -- spending as
much time as you spent getting comfortable with C.  Open your mind a
little.  Then see if you'll feel the same way.  Computer science and
algorithm analysis has its place.  So does assembly language.

	- Scott