Re: [remote] Make registers network byteordered?

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present the target sends back registers in target byte
Andrew> order format vis:
Andrew> [...]
Andrew> General comments?

As the proposal only goes as far as any register values returned by
the 'T' response (and perhaps those sent by the the 'P' command), I
wonder if there is enough value there to implement it?

You mentioned that with the registers being represented in network
byte order, you would be able to determine when a bi-endian target has
switched byte order.  But to accomplish this, you'd need to be able to
ensure that all registers fetches/stores used network order otherwise
pure chaos would erupt.  

For example, the 'p' command to fetch a single register doesn't exist,
either in the code or the spec, so there is no way to fetch the
processor's status register to know what the current endianess is.  I
once experimented adding a 'p' command just to parallel the existing
'P' command, and found that performance was greatly impacted, since 
many register writes were used instead of one 'g'.

I think this is yet another thing to put on the list of deficiencies
in the remote protocol's handling of registers, and that all should be
addressed with a new set of fetch/store register protocol commands. 

The list as remember them:

        * The spec does not nail down the offset, length, and
          representation of the registers in the g/G command.

        * With the g/G command you fetch/store all registers, with P
          you store just one.  In a lot of cases, all you care about
          is a subset of registers (integers, fpu, pc+fp+sp, etc).

        * fetching and storing registers is one of the most common 
          protocol operations, but there is no way to transfer them
          in binary (as there is for memory write).

Any more?

        --jtc

-- 
J.T. Conklin
RedBack Networks