Re: [RFC] New targets remote-rx and extended-remote-rx

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 30 Apr 2010, Kevin Buettner wrote:

> +   Within an executable file, words in code sections are stored in
> +   in `memory order'.  Thus words in an executable file could be
> +   directly transferred to an RX target's memory without requiring
> +   any swapping.  `Memory order', however, is often not the most
> +   natural order for the rest of the toolchain to operate on the
> +   instructions.  E.g, when disassembling a sequence of instructions,
> +   the disassembler will want to look at the instruction bytes in the
> +   same order as that with which the execution unit of the chip sees
> +   them, i.e, it'll want to look at them in `execution unit order'.

The issue of having memory order different from execution unit order is 
not unique to the RX, so one question would be what is the right general 
approach to handle such issues for other targets as well.

The case I know of is the TI C6X processors (C64X+ and C674X are the only 
ones affected by this issue).  The C64X+ and C674X have a compact 
instruction encoding where some instructions are 16 bits and some are 
32 bits; 256-bit fetch packets can have a header saying which 32-bit words 
are a single instruction and which are two 16-bit instructions.  In 
execution unit order, the least significant half of a pair of 16-bit 
instructions always comes before the most significant half, leading to 
them being out of order in memory order in the big-endian case.

On this processor, branch instructions work with logical addresses, where 
a 4-byte-aligned address pointing to a pair of 16-bit instructions always 
refers to the least-significant - first in execution unit order - of those 
instructions, rather than with physical addresses.  External code symbols 
are required to be 4-byte-aligned (most branch instructions only support 
4-byte-aligned target addresses).  (The ISA manuals don't make this clear, 
but it's been confirmed with TI that this is how the processors work and 
what the ABI should be.)

We haven't yet started the GDB port or the assembler support for 16-bit 
instructions, but for the disassembler the approach we've followed (see 
opcodes/tic6x-dis.c, which can handle 16-bit instructions to the extent of 
knowing what's 32-bit and what's 16-bit although they aren't yet in the 
opcode table), which is also the approach followed by TI's tools, is that 
when asked to disassemble the instruction at a given address it treats it 
as a logical rather than a physical address.  So BFD doesn't need to do 
anything special regarding this peculiarity, but the assembler will need 
to swap instructions at the last minute when it gets support for 16-bit 
instructions, and of course there may be GDB issues such as you found (but 
possibly a different set of issues because of not making BFD do the 
swapping).

-- 
Joseph S. Myers
joseph@codesourcery.com