From: kortink@cs.utwente.nl (John Kortink)
Subject: Yes, more .....
Organization: University of Twente, Dept. of Computer Science
Date: Sun, 4 Oct 1992 12:46:59 GMT

Another long, boring story. Hit 'n' now if you're allergic.

crj10@phx.cam.ac.uk (Clive Jones) writes some things that warrant one
last reaction to this boring cock-fight :

>It should be borne in mind that John Kortink has a somewhat unusual
>perspective on matters, simply because he's into image processing
>(from what I've seen of his software).

Then you haven't seen my BBS software, or PackDir, or any of my
hardware designs for the Arc.

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

>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