From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 21 Aug 1992 01:10:37 GMT

In article <1992Aug20.164900.13800@oracle.us.oracle.com> mfriedma@uucp (Michael Friedman) writes:
>In article <5242@unixhub.SLAC.Stanford.EDU> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>>In article <1992Aug19.160844.13884@auto-trol.com> davgot@auto-trol.com 
>>(David Gottner) writes (edited):
>>>I have complete control of the hardware with some HLL's (like C).  If I want
>>>a left shift I use '<<'.  If I want a signed multiply I use '*' on two signed
>>>numbers.  What more control could I want?
>
>>>I suppose that there are >>some<< limitations.  You can't write interrupt
>>>routines with standard C, but that is what assembler is for.  However, C
>>>gives you so much control that assembly is rarely necessary.
>
>>Nonsense. There are many (efficient!) things you can do in assembler
>>but not in C. And I'm sure even the best optimizing compilers don't
>>know all the tricks you can pull in assembler.
>
>>- If I call any subroutine or function in C, a large set of registers
>>  will be saved in some fashion, often unneccesarily.
>
>And in just how much of your code is this an important issue?  I don't
>think anyone denies that assembly can be a massive performance win if
>you use it in a tight loop that takes up most of your execution time,
>but most code isn't in tight loops that take up most of your execution time.

You're barely scratching the surface of what assembler does.  In C, the
calling convention may be more overhead than the subroutine!

>
>>- When I want to test a particular bit in assembly language, I have
>>  several ways of doing it (in the Z80 for example I can rotate if it
>>  was the first or the last bit, I can mask and test, or I can do a bit
>>  test instruction). In some situations, some of these ways may be
>>  better than others. How do you
>>  express these minute differences to your C compiler ?
>
>You don't.  Once again, unless speed is absolutely critical you don.t
>need to, and even in those applications in 99% of the code it doesn't
>make a difference.

Again, it's debatable.  This argument is like a crumbling house that's
falling apart bit by bit, you keep saying the house hasn't fallen down
yet so keep on doing the status quo.  One day, the house falls down.  Programs
tend to not be usable when tons of avoidable overhead are piled into them.

>
>>- If there is a useful routine (like output a character) which is
>>  provided with a strange calling sequence (the character has to be in
>>  register X and a function code in register Y), I can not use it from
>>  within C, because there is no general way to express all possible
>>  calling conventions. 
>
>If the C library is implemented right then putc will call that function.
>
That's a big if.  Do you seriously believe that C libraries are in tune
with what assembler people would expect to exist on many machines?  On
given machines, there may be literally hundreds of calling conventions
suitable for assembler; do you expect a C library to have all of them?

Besides, this presupposes that the function is expressable as a closed
subroutine or function, which is an abstraction beyond what most good
assembly people would permit (such as co-routines).

>>  If I even touch
>>  putc or printf I am deep in the mess of a horrible run-time-library,
>>  which is liable to be a lot less efficient.
>
>So what?  Once again, in what percentage of your code is this a
>significant issue?

It depends.  Besides, his point is that the available library discourages
his use of a known techniques in favor of more abstract, common, but
inefficient ones.  If he writes in assembler, he can define his own "rules" and
not be stuck with someone else's inappropriate ones.

>
>>- If I need a really tight timing delay loop (say a microsecond), I
>>  just sit down with the CPU manual, count clock cycles, and do the
>>  correct number and type of instructions (pick the correct instructions
>>  to get the right number of clock cycles). I vaguely remember doing
>>  that for HOURS to get a tape reading program to work exactly right.
>>  How do you do this in C ?
>
>You don't.  You don't do it in assembly either unless you're writing a
>one-time application or you have absolutely no choice.

Wrong, this was posted earlier.

>
>What the heck are you going to do when your customer gets a clock
>speed upgrade?  Or a processor upgrade?  Or faster memory so that the
>instructions get loaded faster?

Irrelevant.  Go look at the code.  I am running the same version of Kermit
on my 286 and 386.  What does loading faster mean?  Do you ever actually
use assembly language?

>
>>So, C is not the answer to all questions. There are LOADS AND LOADS of
>>things which can not be expressed in C; and there are some thing which
>>any HLL compiler will do less efficiently than handcoded assembly.
>
>Of course.  On the other hand, I'll bet that less than .1% of code is
>appropriately assembler and less than .001% of applications are
>appropriately 100% assembler.

This is a technical debate, not a popularity contest; the answer can be
appropriately twisted up and down by clever tricks of statisticians.

>
>>Note: I am not advocating writing everything in assembler. That's
>>crazy. But good hand-coded assembler still has its place, in
>>particular in the tight spots of device drivers and realtime systems
>>(where every clock cycle counts). Therefore I agree that assembler is
>>RARELY neccessary.

To reiterate a little:

I never claimed it was either; I resent those that would belittle assembler
to the point that they wish it would "go away".  Their fanatic viewpoints
are as crazy.

cjl
Newsgroups: alt.folklore.computers