From: neeri@iis.ethz.ch (Matthias Neeracher)
Subject: Re: The need for an assembler (was: Favorite CPU)
Followup-To: alt.folklore.computers
Organization: Integrated Systems Laboratory, ETH, Zurich
	<1992Aug19.160844.13884@auto-trol.com> <5242@unixhub.SLAC.Stanford.EDU>
Date: Thu, 20 Aug 1992 10:33:46 GMT

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.

This is somewhat architecture dependent.

>- 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. No problem from within assembler.

Not necessarily. Some compilers are quite good at being able to honor
nonstandard calling sequences.

>- 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).

Counting clock cycles isn't what it used to be. First of all, clock frequencies
change about every year, so any program which is dependent on clock frequency
is likely to be stuck with low end machines in a short time. Secondly, modern
microprocessors with all of their caching mechanisms make getting an accurate
timing this way quite difficult, not to say impossible.

>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.

If I were trying to be nit-picking, I could object that for every program that
is coded more efficiently in assembly, a compiler can be augmented to recognize
the corresponding HLL program and generate the exact same assembly code.

>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.

I agree with that paragraph.

Matthias

-----
Matthias Neeracher                                      neeri@iis.ethz.ch
      "What men are poets who can speak of Jupiter if he were like
       a man, but if he is an immense spinning sphere of methane
       and ammonia must be silent ?" --Richard P. Feynman

Newsgroups: alt.folklore.computers