From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favori
Date: 19 Aug 92 18:36:29 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <NEERI.92Aug18180729@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>In article <1992Aug14.074141.21987@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>*good* assembly programmers do not optimize their code, they write it
>>correctly the first time.
>
>Correctly or optimal ? And does this sentence mean that we finally agree that
>Mel was no good assembly programmer :-) ?

Let's not start that up again!  The constraints of Mel's situation don't apply
to anything since.  In his time, optimization was all that mattered because
he was fighting rotating memory where small changes made drastic performance
differences merely by being in different, albeit similar addresses.  This
kind of housekeeping is totally meaningless on any system since the days of 
core storage (later RAM), not drums, were where your program runs from.

In any case, rather than take literally a facetious response to another
facetious statement, let's stick to something resembling facts or information.

My point is that after a reasonable effort to understand an architecture, the
typical *good* assembly programmer knows how to write the best possible code
for a majority of common program details.  Overall algorithms might yield to
better ones, but I am referring to essentially the best hand method to code
a particular well-focused procedure.  Such code becomes essentially "second
nature" to a good assembly programmer, and thus the code is "correct" the
first time.  At least in the sense that the majority of it isn't a candidate
for rewriting for any reason related to technique per se.

>
>> I am not claiming I am
>>at the top of this category by any reckoning, but I think that a fair amount
>>of the code I have written over the last 24 years wouldn't ever be optimized
>>by me or anyone else at any point because it truly is the best way to deal
>>with the specifics at hand.
>
>This sounds somewhat vague to me. Do you claim that your code can not be
>made faster in any way, or that it wouldn't be worth the effort ?

Again, under the constraints of algorithmically not changing what's being
attempted, the answer is that literally, this is the "correct" way to do
what it does.  Of course, a lot of it would get replaced if there was a
need to, but only because of differing specs or to take advantage of any
alternate overall algorithms.

Let me make a simplified example:

Let's say on an arbitrary machine that I was ignorant of the existence of
an instruction that counts down a register by one each test instruction, and
it conditionally takes a branch only if zero result, else falls through.  
Since I didn't know the instruction exists, I use an inefficient but effective
method of using a general register and subtracting literal one from it, and
then testing for zero result.  Clearly, a more inefficient mechanism.

All code I wrote for such a machine using the latter method is poor code.
It should be rewritten, and possibly might if there was sufficient reason.
Later, I discover the existence of the former instruction, so I switch over
and always use the former, never again the latter.

My point is that now, all code I write is optimal and "correct" for this
sort of purpose, unless unbeknownst to me there is yet another operation on
the machine.  The point is that this all converges quickly to a point where
you "know" the machine and just write that correct code that is optimal for
that kind of problem.

Now if someone comes along and publishes an alternate algorithm that avoids
loops altogether, then the code, although optimal for its implementation,
now has been proven to implement a less-than-optimal algorithm.  In this
case, the code may be rewritten.  And the new code will be done in the
correct way for it to be implemented as well.

The time frame for this learning curve is a small fraction of the time
line where the architecture is viable.  There are few exceptions to this.

I hope this explains my point a little better.
>
>On the other hand, this would still give a lifetime of 680X0 based Macs of
>about 15 years, which is more than enough to justify learning assembler.

I guess we agree on this point completely :-).

>
>>DEC is saying that
>>the Alpha chip is going to take them well into the next century.  I guess that
>>means we shouldn't learn it either to any extent because DEC might retract
>>that statement any time now, right?
>
>No, that means that DEC has made a prediction for a timespan which is almost
>as long as their current existence. It seems to me that DEC is trying to
>announce the end of progress in architectural design, which to me just seems
>*slightly* premature.

I don't agree; DEC isn't an end-all, be-all company now, assuming anyone
ever thought it was :-).

In any case, I think they are serious to their notion that Alpha will be around
for quite awhile, and thus assembler on it should be looked into.

cjl
Xref: sparky alt.folklore.computers:12609 alt.3d:866