From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 12 Aug 92 17:16:53 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL3

ketil@edb.tih.no (Ketil Albertsen,TIH) writes:

[ quotes are extracts, hopefully not out of context, from a long article ]

: This is definitely far from reality! I think it is a safe bet than in any 
: reasonable amount of code, the difference between c and asm, the best you 
: can hope for is a doubling of speed. If you want to speed the total system 
: by 10% - anything less isn't worthwile - you must find a section consuming 
: at least 20% of the time. In most modern systems, that will be a significant 
: chunk of code! (Although not 20% of the code lines, hopefully.) 

I think that this is more true for modern RISCs than for other
processors.  Computer designers have removed a lot of instructions
from CPUs because high level language compilers never generated them,
and therefore they were very rarely used.  If your computer has a very
small, simple, regular instruction set it's that much more likely that
a compiler will do a good job with it.

However, there remain cases which are often easy to handle in assembly
language but difficult in high level.  One thing which is available in
assembler but not in C is mixed precision arithmetic.

For example, a*b/c will often overflow in C; in assembler
multiplication of two 32 bit numbers should return a 64 bit number,
which can then be divided by a 32 bit number to give the correct
result without overflow.  In C you are at the mercy of the compiler
writer to provide "long long" or somesuch.  Also, in assembler you can
get the remainder and the quotient of an unsigned 64/32 division at
the same time, which is what is needed for multi precision arithmetic.

: There *are* applications where small sections consumes far more than 20%, 
: such as the Prolog kernel and arithmetic routines - but the problem for 
: the asm coder is that these conditions are usually well known by the 
: compilers, and they regularly do a very good job themselves.

Sure, these are small sections of code; there's no point in writing a
large amount of assembler.  I don't think a C compiler would generate
good code for the multiprecision arithmetic example above, however.

The ultimate absurdity I've seen on some RISCs is to remove the mixed
precision ops altogether because "C doesn't use them"!

: I repeatedly claim that the major expense in software development comes 
: from what you don't do, not from what you do. If you try to leave out
: "unnecessary" instructions because you *know* that the pointer is non-NULL
: and doesn't need to be checked, that the numeric range of a variable will
: not be exceeded, that the record passed as a parameter is of the correct
: type - when the system crashes at a prestige customer at a critical point
: in time beacause the pointer *was* NULL, the range exceeded etc.etc, *then*
: you see the cost of software development.

It depends on how much hardware your software is amortized over.  If
your program goes into 10,000 tiny single chip computers, you care
about _every instruction_.  There are millions (billions?) of
computerized widgets out there which form an increasing part of the
computer market.  Checking every pointer and array index might mean
that a program will no longer fit in memory, so the whole system has
to be redesigned around a different processor that maybe needs more
power, so the battery pack has to be made larger, etc., etc.

You're talking about your own experience with your chosen market; my
experience differs.  If my using assembler results in a lower quote
for a contract, then the chances are I'll get the business.  And if
the cost of the hardware is included in the contract, it's part of
my costs, which naturally I want to minimize.

Andrew.
Newsgroups: alt.folklore.computers