ARM and virtual/raw registers

[Richard Earnshaw <rearnsha at arm dot com>]

Ok, so it's clear that the current ARM code for handling virtual and raw 
registers is wrong...

So the question is, what does it need to be?

The answer is that I'm not quite sure, since there are a number of factors 
involved here.

1) FPA registers are multi-precision -- that is, they are modal, holding 
information about the type of result in the register at any particular 
time.  The extra information is used to enable correct support of type 
conversions with signalling NaNs.

2) The format of that information can depend on the hardware present, or, 
if absent, on the emulator being used (different emulators handle this in 
different ways).

3) Some of the emulators use three words to hold the raw information, some 
use four.  RDP returns uses four words.

4) When a floating point value is stored in memory the format of that 
memory may depend on the instruction used to store it.  For example, the 
sfmfd instruction used in a prologue sequence will store three words (as 
would stfe), but there may be information in the unused bits that 
indicates the type of the value in the register.  The format of this 
memory may, or may not, be the same as the three-word register information 
mentioned in 3) above.

5) All of the above is poorly documented ;-(

6) Selecting the correct conversion routine may involve some inspired 
guess-work :-)

In addition to the above, we also have the case of the CPSR register.  On 
old ARM chips (or on non-thumb chips up to armv4), this register is, or 
can be mimicked as being, part of the PC.  This suggests to me that the 
current decoding shenanigans that are currently hidden in some of the 
back-end code should probably be moved into the virtual-raw conversion 
layer.  That is, register_convirt_{to,from}_virtual(CPSR) (or whatever 
it's really called) should be responsible for the updating of raw-PC or 
raw-CPSR as appropriate.

Comments?

R.