From: goodwin@edieng.enet.dec.com (Pete Goodwin)
Subject: Re: Yes, more .....
Organization: Digital Equipment Corporation
Date: Sun, 4 Oct 1992 20:21:46 GMT


In article <1992Oct4.124659.24875@cs.utwente.nl>, kortink@cs.utwente.nl (John Kortink) writes...

>>However, his statements about the relative merits of C and assembler seem
>>to be unreasonably absolute!
> 
>I might agree with you here. The fact is though, that we are trying to get
>a point across. And as far as I'm concerned, yes, ARM code is absolutely
>always the better choice, when time is of lesser concern. When there's a
>need to issue more applications in the same time span, then C is a viable
>candidate. I'm not blind, it happens all the time. I'm just curious about
>the reasons. Why does it happen when people see CC's policy, of which
>non-compromise coding in ARM is a major ingredient, see it working, and
>see it grow to possibly the most succesful software seller in the Arc
>scene. It still has not been acknowledged by my 'enemies', there's always
>this 'yes, but see what happens if' catch.

I've not tried coding in ARM; I'm happy to work in C, and use the RISC_OSlib.
I have coded a large project in assembler (six teams, 30 people in all). In
terms of raw speed, assembler is hard to beat, even by an optimising compiler.

As an example I wrote a simple program to print "Hi there!". In C it came to
4k, in assembler 300 bytes (less?).

The problem with assembler, in general, is that it needs more effort to get
something going - in C things can be working quickly. C isn't necessarily the
best language for written 'supportable' code but it gives all the features
other languages lack.

> 
>>John's position - that Arm assembler is more readily ported to new
>>platforms than C is *very* shaky. For a start, assembler programmers
>>would need a new assembler in order to upgrade code, in direct
>>analogy to the new C compiler needed by C programmers.
> 
>I would not be surprised that, because of the sheer simplicity of writing
>an assembler for an ARM, this has been done in-house by CC. Even if it is
>not, it is much, much easier to upgrade the assembler. This was the point
>that I was trying to make : yes, same case, but much easier.
> 
>>However, the assembler programmer also needs to update his code, rather
>>than merely rerunning his makefile under the new compiler. John seems to
>>be living in a daydream world where each person has only one program which
>>would need conversion - in practice tens of programs would need porting, and
>>an automatic port would save the time needed in porting each and every
>>one of those programs.
> 
>It depends on how many ARM coded applications are around that need updating
>and how many people are available to do the conversions. It also depends
>on the complexity of the updates. The whole argument is irrelevant when :
> 
>a) The new processors can run old code : because the large space/time
>   benefits of ARM code are already out there. There would only need to
>   be a focus on what new features could be used to further speed up
>   the code.
>b) The new processor's main speed advantages are 'transparent', i.e.
>   we only need to refer to the main ARM2 and ARM3 difference : the cache.
>   Its benefits are automatically used by any code. And can be controlled
>   much better by ARM coders for that matter.
>c) The new processor's instructions do not cover new ground. This is quite
>   likely, as the whole idea of the ARM was to provide a load/store
>   architecture with a reduced instruction set that would cover >95% of
>   all code ever produced. It is quite unlikely that any totally new
>   instructions would enable much greater efficiency to be achieved. Even
>   if there were a few, would it increase speed that much on an average
>   ARM code program ?
> 
>>Besides, a new C compiler can produce more optimised code even without
>>a new processor, which is instantly of benefit to all C programmers
>>without any effort on their part.
> 
>The best optimizer is the human brain of the ARM coder (or the compiler
>builder for that matter). It has already been addressed ad infinitum in
>past discussions. It just takes more time, but a good ARM coder can
>squeeze out much more than a C compiler's optimizer can.
> 
>>[...]
>>However, only a fraction of the typical project needs to be in armcode -
>>run a C program with function call profiling, and you'll soon realise that,
>>between the extremes of C on the one hand and Armcode on the other, coding
>>say 1% or 2% of a project in armcode can often tilt you over half way
>>towards the speed efficiency of a 100% Armcode program.
> 
>That is obviously true. But half way is only half way. Obviously some ARM
>code constructs are hardly beneficial themselves. When knitting them all
>together, the benefits over C become much more apparent. It can be as
>simple as the way C calls a function (i.e. with sometimes considerable
>wasted overheads), and how it can be done in ARM code. It can be as complex
>as an LZW routine, which can be squeezed down to heart's content, using
>lots of smart tricks, by the ARM coder, while the C programmer has his
>hands tied.
> 
>>So - C and armcode are both useful. If you need block-structuring to
>>provide clarity in a particularly complex algorithm, then mixing in a
>>bit of Pascal will also help. You need to trade off source clarity,
>>development effort, maintenance effort, runnable image size, execution
>>speed and portability - and they contradict.
> 
>Ask CC how they did their pure ARM code then. Maybe you'll learn it's
>not always necessary, this forever compromising, misguided rational attitude
>towards coding.
> 
>If anything torques me off it's this attitude (I don't mean that personally).
>Why don't we all buy PC's for that matter. If we were just as rational about
>buying hardware, we would. And we would never see the benefits of a sleek
>design like the Archimedes. Which was built for speed.
> 
>I always wonder, do these people really exist, which would say to CC : 'It's
>in ARM code ? Oh no, it should be in *C* ! I don't want this !'.
> 
>>Where the boundaries lie for a given application is a matter of taste, but
>>if you rigidly take an extreme position you run the risk of wasting a lot
>>of your time, or pricing your product out of the market for that 10% speed
>>increase
> 
>It is not 10% it is 200 to 300% when coding is done well. This is by
>experience. Maybe you should ask Acorn about RISCOS 3.1 and why there's
>so little C in there.
> 
>>or not being able to make that Unix version you need, or coming unstuck
>>when you need someone else to add some code to your application.
> 
>I do agree with you there though. But properly, spaciously commented ARM
>code can be readable too (I can usually still understand my own ARM code
>after a year or so. Not always, usually).
> 
> 
>John Kortink
> 
>Student of Informatics at the University of Twente, The Netherlands
>(God, will I ever stop doing things 'on the side' and get it done?)
>NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
Pete Goodwin
goodwin@system.enet.dec.com