From: kortink@cs.utwente.nl (John Kortink)
Newsgroups: comp.sys.acorn
Subject: Re: Yes, more .....
Date: 6 Oct 92 00:52:01 GMT
Organization: University of Twente, Dept. of Computer Science

torbenm@diku.dk (Torben AEgidius Mogensen) writes :

>[... read back in c.s.a. a bit ...]
>
>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.

Now there's a novel idea. Yes, I must agree there. If superscalar
architectures arrive, they will be hell to program in machinecode.
Paralellization of code, along with the explosion in size of code
that is happening and will continue, will be ideally suited to be
solved by something that can work intelligently in a global way.
Still, that goes for anything towards higher complexity.

What can happen though, is that when a well-defined synchronisation
scheme exists for a superscalar architecture, and the problem at hand
lends itself by nature for paralellism, it may again be possible for
a machinecoder to significantly improve bandwidth use.

I somehow doubt however, that Acorn, or anyone for that matter, will
have a mature superscalar product ready in the next 5 years or so.

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

And the ARM coder will replace his BL <macro> with the new instruction.
There's no difference here ...

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

Quite the contrary. An assembler coder will have optimized code all
around, because it is all written by him. A compiler can only optimize
locally, i.e. knit together BL <somewhere>:MOVS PC,R14, and do some
register optimizations. The assembler coder furthermore is ideally
suited to use real human intelligence in optimizing the critical
routines. That's the fun of it after all.

>Furthermore, optimization is implementation dependent, so code that is
>optimal on one processor may be suboptimal on another.

That is of no concern. ARM code is not to be ported. And I would
seriously doubt code optimal on ARM3 would be significantly suboptimal
on ARM7xx.

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

True. Headaches for machinecoders. But don't jump to conclusions. Wait and
see what happens and what is possible and what is not with parallel
architectures.

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

Logically, you make a big mistake here. Compilers are also written by
human coders. And after that, behave like computers (i.e. not inventing
any new tricks themselves !). Big difference.

Anyone can code ARM. I'd like people to test themselves more on that
rather than relying on C. It's a big thrill to know you run your code
at max., the way it was meant to be ... Think about it. (It takes time
though, chopping up your high-level thoughts into composing particles
is only the start, that's only what compilers try to do).


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
Newsgroups: comp.sys.acorn