From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.sys.acorn
Subject: Simple idea for next ARM generation.
Date: 14 Apr 92 13:47:45 GMT
Organization: Department of Computer Science, U of Copenhagen

This is another of my inane ramblings about possible extensions to the
ARM processors ;-)

This one is presumably simple to implement and it doesn't require
extra instructions. Instead it slightly modifies the semantics of the
current instructions, but without causing loss of backwards
compatibility!

The idea concerns the flags and the S bit in the arithmetic
instructions. A present the flags are modified if and only if the S
bit is set (except the compare instructions, where the S bit is
implied). My idea is to have an extra set of flags, which are modified
exactly when the S bit is not set. This way all arithmetic
instructions will modify one of the sets of flags. Unfortunately,
testing these flags is not going to be as easy. The simplest solution
is to let the programmer explicitly access the flags in the status
word (I'm thinking ARM6 here), but that would require using a CMP or
similar which will modify the "original" flag set. Instead I propose
that the NV (never) condition test the new flags. To allow different
conditions to be tested, the status register can contain a condition
code. Thus, if a NV condition code is seen, the condition code in the
status register is matched against the new flags, and the instruction
is executed if the match succeeds. By defaulting the condition code to
NV, the NV condition code in instructions retains the semantics from
previous ARM processors.

Granted, modifying the condition code in the status register takes
time, but in a loop it is only needed once in the initialization part.

What then is the benefit from such a scheme? Well, it allows flags to
be modified in a block of instructions that are conditionally executed
without affecting the remaining instructions in the block. As an
example, suppose you want to add a two 64 bit numbers if a condition
is true. Since the 64 bit addition requires use of the carry flag, you
would normally have to jump over the addition instructions, giving the
following code:

	<instruction modifying old flags (S set)>
	B<inverse of condition> label
	ADDS R0,R2
	ADC  R1,R3
     .label

If you assume that the condition code in the status register is set to
the appropriate condition, the code will be:

	<instruction modifying new flags (S clear)>
	ADDNVS R0,R2
	ADCNV  R1,R3

Another application would be a parameterized stop condition for a
loop.

The main problem I can see with this idea (apart from the asymmetry of
the two flag sets) is that fetching the condition code from the status
register will delay the pipeline. However, I don't think it will.
Presumably (correct me if I'm wrong), a condition code is tested by
putting it through a PLA (or similar) together with the flags from the
status register. Hence, the status register is already accessed in
this part of the pipeline. The PLA could be extended so it accepts
both the condition code from the instruction and both flags sets and
the condition code from the status register. The new PLA would be
twice as wide and (as far as I can calculate) twice as high as the
present one, taking up 4 times the area. In the present ARM, a naive
PLA implementation of the condition codes would require a 21 high 16
input AND part and a 21 high 1 output OR part, but by using the fact
that the last bit in the condition code negates the condition, it can
be reduced to a 10x(16+1) PLA and an XOR gate. A similar trick can
reduce the new condition code system to two 10x(16+1) PLAs, an XOR
gate, 3 AND gates and an OR gate. This is only about twice the present
area, and that should not be a great part of the total processor area.

	Torben Mogensen (torbenm@diku.dk)