From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 20 Aug 1992 15:23:36 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

In article <5242@unixhub.SLAC.Stanford.EDU> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>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.

Where you got that stupid compiler from? I thought such crapware
died long time ago..

>- 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. Example: I just read the status register from a
>  device.  If I don't need the register any longer, I just mask the bit
>  I want with an AND and check the result for zero/nonzero; this is the
>  fastest method. If I care about the whole content, but need a quick
>  look at the top or bottom bit, I rotate the registers so the desired
>  bit walks into the carry flag and test that. Only if I really need the
>  whole status register unmodified do I have to do a slow bit-test
>  operation, or waste another register on saving/testing. How do you
>  express these minute differences to your C compiler ?

I haven't. If you write "if( i & 0x80 )" and later never use i
compiler is free to choose any of the methods you just mentioned.
In fact i saw actual compiler doing those (and much more non-trivial)
things. It's the difference between good and bad copiler (and the
difference between good and bad assembler programmer). Though you
need to write a good compiler only once; and it's much easier than
to teach a zillion of good assembler programmers.

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

Better replace this useful routine with something keeping
calling conventions. It'll be MUCH more useful.

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

That's the YFOS problem, not the language. putc is an inline in the
most C implementations, btw.

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

Then YFM inreases the clock rate of the processor (or silenlty changes
timings) and your programs go banana. To deal with SO brain-dead
devices as you described is what assembler is for. Fortunately
99.99% of the hardware do not require in-line delays with nanosecond
precision.

>So, C is not the answer to all questions.

Nobody claimed it.

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

Don't exaggregate the importance of those things. Average assembler
code in Unix takes about 2% of the all kernel code. And tight
requirements on gadget programmming usually mean poor overall
design. Spending a bit more money on better hardware design (and/or
hiring an electonics engineer with background in programming) can
reduce programming costs by order of magnitude. Speaking from
my own experience...

>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 wish good assembler programmers will devote more attention to
making their experience available to public by writing real good
code generators. It takes years to find all the fine tricks compiler
designers are usually unaware of.

As for realtime systems -- they often emerge from critical applications
where errors may literally cost lives (and many not-so-critical
things like microwave ovens can also kill with the aid of programming
errors). A good reason for type checking and explicit algorithm
expression.

--vadim
Newsgroups: alt.folklore.computers