From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.sys.acorn
Subject: Re: Yes, more .....
Date: 5 Oct 92 15:17:18 GMT
Organization: Department of Computer Science, U of Copenhagen

kortink@cs.utwente.nl (John Kortink) writes:

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

I agree on a and b, but c is likely not to be true in the future. It
is the case that the 32 bit modes in the ARM6 series are no faster
than the 26 bit modes (and may even be slightly slower due to extra
work to handle flags), but when and if a superscalar implementation is
made, it may be difficult to parallelize instructions that modify
flags with instructions that modify the PC when running in 26 bit
mode, thus giving more pipeline stalls than similar code in 32 bit
mode. Also, if an integer divison instruction or 32x32-> 64 bit
multiplication are added, use of these will make new code a lot faster
than old code that uses subroutines or macroes.  A compiler will
automatically use the new instructions.

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

This may be true in most caes, but what will often happen is that, due
to the effort involved, the assembler programmer will only optimize
a few critical pieces of code, whereas a compiler will optimize all.
Furthermore, optimization is implementation dependent, so code that is
optimal on one processor may be suboptimal on another. Recompiling
with a new compiler will optimize for the present implementation. When
the processor is superscalar the scheduling of instructions is very
critical and extremely hard to optimize, both by hadn and machine, but
at least the compiler can look at a lot of cases in a very short time.

The present ARMs are easy to optimize by hand (or machine), as
(almost) every instruction runs in a specific number of cycles,
independent of the context. When this is no longer true, I think that
the superiority of the human coder will soon diminish.

	Torben Mogensen (torbenm@diku.dk)