On Mon, 7 Dec 2009, David Brownell wrote: > Move the ARM opcode macros from <target/armv4_5.h>, and a few > Thumb2 ones from <target/armv7m.h>, to more appropriate homes > in a new <target/arm_opcodes.h> file.
What about changing the names of a couple of those macros as well? Say ARMV4_5_STMIA(). This isn't an instruction for ARMv4 or ARMv5 only. I think all ARM architecture version always had them. I can understand the logic to add the architecture level from which an instructionwas introduced e.g. ARMV5_BKPT(). But all ARMV4_5_* are rather misleading. > Tightening up some of the line lengths turned up a curious artifact: > the macros for the Thumb opcodes are all 32 bits wide, not 16 bits. > There's currently no explanation for why it's done that way... When pushing instruction in the CPU pipeline through scan chain 1 on an ARM9TDMI (or compatible) CPU core, you need to use 32 bits for the instruction field. If in Thumb mode, the 16-bit Thumb instructions have to be duplicated on both 16-bit nibbles of the 32-bit field. >From Section B.7 "Determining the core and system state" of "ARM9E-S Core Technical Reference Manual" (DDI0240A.pdf): | Note | | Because all Thumb instructions are only 16 bits long, the simplest | method, when shifting scan chain 1, is to repeat the instruction. For | example, the encoding for BX R0 is 0x4700, so when 0x47004700 shifts | into scan chain 1, the debugger does not have to keep track of the half | of the bus on which the processor expects to read the data. Nicolas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
