Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!jroach
From: jroach@acorn.co.uk (Jonathan Roach)
Newsgroups: comp.sys.acorn
Subject: Re: C versus ARM
Message-ID: <5538@acorn.co.uk>
Date: 4 Mar 91 12:16:06 GMT
References: <6397.9103011248@olympus.cs.hull.ac.uk>
Sender: jroach@acorn.co.uk
Distribution: comp
Organization: Acorn Computers Ltd, Cambridge, England
Lines: 47

In article <6397.9103011248@olympus.cs.hull.ac.uk> rst@cs.hull.ac.uk (Rob Turner) writes:

> .... Large lump describing the translation of assembler to C deleted ...

>As long as all our variables were global (as in [most] machine code),
>and all our functions had no parameters, I find it hard to believe
>that the resulting compiled program would be only half the speed of
>the native ARM program. Surely it would be faster than that.


Here we can now focus on what really makes the difference between assembler
and C - the passing of arguments and results from functions. In Rob's
discussion of translating assembler to C he rightly concludes that the
function bodies will be at least as effecient when written in C as when
written in assembler, indeed the compiler may make a better job of
the optimisations that the original assembler programmer :-) (Aside: I note
that some optimisations can be done in assembler which the compiler cannot
safely do itself, and that some assembler instructions are simply not
accessible from C directly - these have an impact on the code size, but for
most accademic programs (which don't have to mess with the processor mode,
and interface heavily with the OS) the effect is small. End aside). What the
compiler in this particular case gets really hammered on is the necessity of
storing away any of the changed 'registers' in their global locations before
calling any functions, and obtaining the values it needs from these global
locations after the function call. This is an enormous overhead! Also,
assuming use was made of function parameters and the return value, C is
still at a disadvantage as it can only return *one* value from a function.
This value, admitedly, could be a whole structure, but, given the particular
calling standard used on the ARM, this doesn't help as you're stuck with a
single 32-bit value.

So, in summary, when writing in C, you may (and probably will) gain in the
function bodies, just to have it thrown away again at function entry and
exit. So, what does this mean? Well, if the size of your final program is
paramount, and you're prepared to put up with a higher code maintenance
cost, then code in assembler (I have not yet been convinced that the
C:assembler ratio is better (for C) than 1.2:1, which goes up to about 2:1
if there's a lot of SWI calling to be done (which is very cumbersome when
done from C, but real natural from assembler :-)). If you're not too worried
about the final code size, then code carefully in C (with comments,
meaningful variable names (with syllables in them :-), indentation etc etc)
In any case, whatever you're coding in, write code which, if you hadn't
written yourself, you wouldn't be boggled by its obscurity if you had to
figure out what it did. Why? - you're going to be reading this code in about
2 weeks time when you've probably forgotten what the **** it did !!!

--Jonathan