arm - segmentada - tipos de arquitectura de computadoras pdf

Acerca del valor de la pc del brazo en la secuencia de instrucciones mixtas de 16/32 bits

Question

Leí un par de artículos, incluida la pregunta aquí en SO ¿Por qué la PC ARM registra el punto de la instrucción después de la siguiente para ser ejecutado? , ese valor de registro de la PC es en realidad la dirección de instrucción de ejecución más 2 instrucciones más adelante, por lo que en el estado ARM es de +8 byte (2 * 32 bits).

Mi pregunta es que, para el estado de pulgar, podría haber instrucciones de 16 bits o 32 bits, ¿significa que la dirección de la PC de búsqueda podría ser un desplazamiento de +4 bytes O +8 bytes para instrucciones de 16/32 bits, respectivamente?

Por ejemplo:

279ae6: f8df 9338 ldr.w r9, [pc, #824] --> pc value= 279aea or 279aee
279aea: f44f 7380 mov.w r3, #256
279aee: 48cd ldr r0, [pc, #820]

Hice más pruebas con el siguiente código:

1598: 467b mov r3, pc
159a: f8bf 4000 ldrh.w r4, [pc] ; 159c
159e: 46f9 mov r9, pc
15a0: f83f 5001 ldrh.w r5, [pc, #-1] ; 15a3
15a4: f83f 6002 ldrh.w r6, [pc, #-2] ; 15a6
15a8: f83f 7003 ldrh.w r7, [pc, #-3] ; 15a9
15ac: f83f 8004 ldrh.w r8, [pc, #-4] ; 15ac
15b0: f04f 0908 mov.w r9, #8
15b4: f8d9 0008 ldr.w r0, [r9, #8] ; Trigger crash to check registers

Tras el colapso, los registros son:

I/DEBUG ( 2632): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10
I/DEBUG ( 2632): r0 b8ef4fc0 r1 aca6bb6c r2 00000000 r3 aca7c59c
I/DEBUG ( 2632): r4 00004000 r5 00003f50 r6 00006002 r7 000003f8
I/DEBUG ( 2632): r8 0000f83f r9 00000008 sl 00000000 fp aca6bbc0
I/DEBUG ( 2632): ip aca7c591 sp aca6bb40 lr acab722d pc aca7c5b4 cpsr 60070030

Las direcciones que se muestran en los comentarios del código anterior (159c / 15a3 / 15a6 / 15a9 / 15ac) son generadas por objdump, verifiqué el contenido de estas posiciones con los registros, parece correcto.

para 16 bits instrucion:

1598: 467b mov r3, pc ; // r3 = 1598 + 4 = 159c, correct for +4 theory

Mientras que para la instrucción de pulgar de 32 bits:

159a: f8bf 4000 ldrh.w r4, [pc] ; // ld addr = 159a + 2 = 159c, where the content is 4000(hw), exactly r4 shows
; // Inconsistent with +4 theory

Con esto, para la instrucción de 32 bits, pc read = pc ejecutando +2. ¿Me estoy perdiendo algo? Ahora estoy realmente confundido acerca de la compensación de PC.

Por cierto, esta es la plataforma armv7a usando thumb2.

Gracias chicos.

Answer 1

El desplazamiento de PC siempre es de 4 bytes en estado Pulgar. La razón es que hay dos lecturas de instrucciones adelante, y una extracción de instrucciones de Thumb es (conceptualmente) siempre una media palabra, por lo que las codificaciones de 32 bits aún tienen el orden de bytes gracioso de dos halfwords little-endian, en lugar de una palabra little-endian.

La codificación de "32 bits" en el conjunto original de instrucciones Thumb, bl , tenía el funcionamiento de cada media palabra definido por separado como instrucciones "prefijo" y "sufijo", el truco perfecto es que mientras se ejecuta la primera parte, la dirección de retorno es tomado directamente de la PC, ya que en esa etapa apunta a la instrucción después de la segunda parte. Para cuando la tecnología Thumb-2 apareció y convirtió las codificaciones de 32 bits en algo formal ( incluyendo bl retroactivamente), el offset de PC no había tenido ninguna relación con la microarquitectura real durante varias generaciones ^* , por lo que su comportamiento definido depende de la la secuencia de instrucciones no habría tenido virtualmente ningún beneficio e introdujo problemas de compatibilidad masiva.

Para complicar aún más las cosas, cuando la PC se usa como un registro base para operaciones de direccionamiento (es decir, adr / ldr / str / etc.) siempre se utiliza el valor alineado con las palabras , incluso en el estado de Pulgar. Entonces, mientras se ejecuta una instrucción de carga en 0x159a, el registro de PC se leerá como 0x159e, pero la dirección base de ldr...[pc] es Align(0x159e, 4) , es decir, 0x159c. Dado que el direccionamiento relativo de PC se escribe normalmente especificando una etiqueta en lugar de calcular las compensaciones manualmente, este detalle puede ser fácil pasar por alto.

_{* En términos de los propios diseños de ARM, ARM7 fue la última microarquitectura basada en la tubería original de 3 etapas.}