오른쪽에는 r13_irq와 r14_irq 레지스터가 보입니다. 이런 종류의 레지스터의 정체는 무엇일까요? Arm 동작 모드에 뱅크드된 레지스터라고 합니다.
뱅크드 레지스터를 주로 기계적인 관점으로 설명해서 소프트웨어 개발자가 이해하기 어렵습니다. 이해를 돕기 위해 다음과 같은 명령어를 봅시다.
sub, sp, sp, #4
sp 레지스터인 r13 레지스터의 값을 4만큼 빼는 명령어입니다. 여기서 sub은 뺄셈 연산 명령어입니다. 위와 같은 명령어를 실행하면 그림 2.1기준으로 어느 레지스터의 값이 업데이트될까요? r13의 종류는 r13_svc, r13_irq, r13_abt 이니, 이 중 하나입니다.
‘sub, sp, sp, #4’ 명령어를 실행할 때의 Arm의 동작 모드가 슈퍼바이저 모드라고 가정합시다. 이 때 r13 레지스터와 r13_svc 레지스터는 같은 값으로 업데이트됩니다. 대신 r13_irq와 r13_abt 레지스터의 값은 바뀌지 않습니다.
만약 위에서 소개한 명령어를 실행할 시점의 Arm의 동작 모드가 IRQ 모드이면 어느 레지스터가 업데이트될까요? 눈치가 빠른 독자는 r13, r13_irq 레지스터가 변경된다는 예측할 겁니다.
r14 레지스터도 r13와 마찬가지로 동작합니다. 이번에는 다음 명령어를 보겠습니다.
01 0xc000a000 bl <sub_routine>
02 0xc000a004 cmp r0, #0
01번째 줄의 명령어를 실행하면 r14 레지스터는 0xc000a004로 업데이트됩니다.
[정보]
'bl' 명령어의 용법은 Arm AAPCS(함수 호출 규약)의 내용을 참고하세요.
위와 같은 명령어를 실행하면 그림2.1 기준으로 어느 레지스터의 값이 업데이트될까요? r14의 종류는 r14_svc, r14_irq, r14_abt 이니 역시 이 중 하나입니다. r13와 마찬가지로 r14 레지스터도 Arm 동작 모드에 따라 뱅크드된 레지스터의 값이 변경됩니다.
01번째 줄의 명령어를 실행할 때의 Arm의 동작 모드가 슈퍼바이저 모드라고 가정합시다. 이 때 r14와 r14_svc 레지스터가 같은 값으로 업데이트됩니다. 이 상황에서 r14_irq와 r14_abt 레지스터의 값은 바뀌지 않습니다.
만약 위에서 소개한 명령어를 실행할 시점의 Arm의 동작 모드가 IRQ 모드이면 어느 레지스터가 업데이트될까요? r14, r14_irq 레지스터라고 예상할 것입니다.
그렇다면 이렇게 Arm 동작 모드 별로 업데이트되는 뱅크드 레지스터를 설계한 이유는 무엇일까요? 바로 Arm 모드 별로 실행 흐름을 저장하는 레지스터가 Arm 모드 별로 있으면 소프트웨어 로직이 간단해지기 때문입니다.
IRQ 모드에서 어떤 코드를 실행하다가 슈퍼바이저 모드로 변경하는 상황을 예로 듭시다.
이 때 IRQ 모드에서 사용된 r13와 r14 레지스터의 값을 어딘가에 저장해야 합니다. 그래야 다시 IRQ 모드로 진입할 때 r13와 r14를 로딩해 이전의 (소프트웨어적인) 실행 흐름을 이어갈 수 있습니다.
그런데 각 IRQ 모드를 위한 전용 레지스터가 있으면 이렇게 r13이나 r14를 어딘가에 백업할 필요가 없습니다. 다른 Arm 동작 모드에서 IRQ 모드로 바뀌면 r13_irq, r14_irq 레지스터의 값은 r13 그리고 r14 레지스터 값으로 매핑되기 때문입니다.
Arm 동작 모드 별로 뱅크드된 레지스터가 존재하는 다른 이유는 무엇일까요? ftrace나 TRACE32와 같은 장비로 성능을 측정하면 실제 디바이스에서 Arm 동작 모드가 굉장히 자주 바뀌는 현상이 확인됩니다. 그런데 Arm 동작 모드가 바뀌면 이전 동작 모드에서 처리된 스택 주소나 링크 레지스터의 값을 어딘가에 백업하고 로딩하는 연산을 수행해야 합니다. 1초에 300번 이상 Arm 동작 모드가 바뀌면 스택 주소나 링크 레지스터를 저장하고 로딩하는 동작을 수행하므로, 성능에 악 영향을 끼칠 수 있습니다. Arm 동작 모드마다 접근할 수 있는 뱅크드 레지스터가 있으니 스택 주소를 어딘가에 백업하고 로딩하는 동작을 수행할 필요가 없습니다.
