Newsgroups: comp.sys.acorn
Subject: Re: Yes, more .....
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Mon, 5 Oct 1992 22:03:31 GMT
Organization: Computer Science Dept. University of Auckland

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

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

I think the most important distinction between 26bit and 32bit mode must
be that function calls will use different code: The flags are now in
different registers - different things have to be pushed and popped on
the stack.
If we are using a compiled language, none of the source code has to be changed
to support the new function call 'protocol', but if we write in assembler,
almost every function will need to be modified to use the new protocol.
John and other assembler-lovers might not mind this kind of work, but
I personally would make a *lot* of silly mistakes in changing a large
program with lots of function calls, and I would be sure to introduce lots
of new bugs. And that's before I start trying to use new instructions
and processor-specific 'tricks'.

>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

The most important thing to note here is: If you want to make use of
processor-dependant optimisations for the ARM-2, ARM-3, and ARM-700,
then you really need 3 executable programs with (for example) unrolled
loops in the ARM-2 version, normal loops and cache-friendly code for
the ARM-3, and 32-bit function calls and new instruction usage on the ARM-700.

If you have 3 C compilers (or 3 modes in the compiler), then you can easily
update your code, and then recompile for all 3 platforms, to get the best
out of each processor.
I would hate the revision control (and work) necessary to keep 3 versions
of a large assembler program for each of these platforms - each change
would result in 3 times as much work.

This is far more important than a once-off few days of work porting the code
to the new compiler, or re-writing assembler for a new processor.

The interesting thing about this whole discussion is that, whether you
realise it or not, practically everybody uses a high-level language for
all the "tedious" stuff (C or BASIC generally), and as we are all power
freaks at heart, if something makes us wait for more than 1/2 a second,
we are moved to re-coding it in assembler to squeeze more speed out of it.
The only cases I know of where assembler is used on its own are:
  Impression/ArtWorks - good packages, but IMO it'll take a lot of work to...

  The operating system - Necessary in assembler, most of it, because most
  of it needs to be fast, and a lot of it (interrupt code, modules) is better
  suited to asm implementation.

  Other desktop applications (Menon, Aidon) - these are *tiny* programs
  compared to 'big' applications, so are much easier to handle in asm.
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)