Re: ARM and virtual/raw registers

[Richard Earnshaw <rearnsha at arm dot com>]

> [And I thought MIPS was bad :-)]

Welcome to the real world where hardware designers get in the way, and 
then software developers add extra things to save some time too...

> 
> So an FP register could contain a single, double, ... and each would be 
> represented differently - single, for instance, would not be stored as a 
> rounded double?

Well, either representation might be used, and I think there exist cases 
where both occur.  For example, a SP value just loaded from memory might 
be left in SP format, with a tag indicating this, or it might be held in 
extended precision.

The only time it gets really nasty is when it comes to signalling NaNs.  
IEEE requires an exception if a type conversion is performed on them (but 
not if the value is just copied/stored/sign-flipped), so the register must 
hold some meta-data on the value indicating the type held, so that we can 
fault if required.  The reason for the SFM/LFM instructions is so that a 
subroutine can stack such values across subroutine calls without causing 
exceptions to occur.

> If this is the only problem, then the new REGISTER_TO_VALUE et.al. 
> methods should address the problem.

Partly, but it puts the conversion in the Arch space, but conversion is 
really dependent on the Target vector, not the ABI (or not just the ABI).

> Those methods, do, however, assume that the format of a register spilt 
> into memory is identical to the layout of the h/w register supplied by 
> the OS / H/W / ...  Hmm, ...

We might be able to achieve this, with some magic, but the format in 
memory isn't guaranteed to be the same for all targets.  That makes use of 
that format undesirable: I'd much prefer to be able to use a format that 
was common to all ARM targets and then have both registers and memory 
normalized to the internal format during back-trace analysis.

> > 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.
> 
> So the way the ARM spills its FP registers into memory may not 
> necessarily match the equivalent h/w register?

Correct, the documentation for the SFM instruction says that the format is 
internal to the CPU, and that the only way to recover the value is to use 
LFM to load it back again ;-)  Of course, that's no good with a debugger, 
particularly a cross debugger.  I don't think there is a problem with 
getting some documentation releases on the format that the FPA hardware 
uses, but I suspect that this won't necessarily match the behaviour of, 
say, the emulator used on ARM/Linux, since that was written without access 
to the details of the way the FPA does it.

> 
> Does the ARM always spill these registers in the same way (at least for 
> a given ISA/ABI combination?) - if GDB is fetching a saved register from 
> the stack, it knows what the format is.

Well, it should, but there's no absolute guarantee.  In practice, some 
code may use SFM (storing in internal format), and other code might use 
STFE (store in extended format) and expect the Hardware/emulator to ignore 
faults when converting to/from extended precision.  Although code using 
these methods *shouldn't* be intermixed, there's certainly no reason why 
multiple applications running on the same platform shouldn't use either 
one.

I shan't bother you yet with details about how the VFP co-processor works 
;-)

R.