x86 에뮬레이터 팀이 너무 나쁜 코드를 발견해 에뮬레이션 중 고쳐버린 일

x86-32 에뮬레이터는 다른 프로세서에서 x86-32 코드를 실행하기 위해 바이너리 변환으로 네이티브 코드를 생성했으며, 인터프리터 방식보다 큰 성능 개선을 제공함

• 해당 에뮬레이터는 x86-32를
  바이트코드처럼 보고, 에뮬레이터를 JIT 컴파일러처럼 동작시키는 구조로 이해할 수 있음
• 한 프로그램은 스택에 약
  64KB 메모리를 할당하고 초기화해야 했으며, 일반적인 방식은 스택 프로브 후 스택 포인터를 줄이고 작은 루프로 메모리를 초기화하는 방식이었음
• 해당 코드의 컴파일러는 루프 대신 65,536개의 개별
  바이트 쓰기 명령을 생성했으며, 각 명령이 4바이트라 64KB 데이터를 초기화하는 데 256KB 코드가 필요했음
• 에뮬레이터 팀은 이 함수를 감지하는 특수 코드를 번역기에 추가하고, 동등한
  짧은 루프로 대체하도록 처리함

배경: x86-32 에뮬레이터와 바이너리 변환

• Windows에는 x86-32가 아닌 다른 프로세서에서 실행되는 시스템을 위해 x86-32 프로세서 에뮬레이터가 포함된 적이 있었음
• 이 사례가 어떤 프로세서에 적용됐는지는 원문에서 특정하지 않음
• 해당 에뮬레이터는
  바이너리 변환을 사용해 원래 x86-32 코드와 동등한 동작을 수행하는 네이티브 코드를 생성했음
• 이 방식은 인터프리터 기반 에뮬레이션보다 상당한 성능 개선을 제공했음
• x86-32를 바이트코드로 보고, 에뮬레이터를
  JIT 컴파일러로 보는 식의 이해가 가능함

문제 코드: 64KB 스택 메모리 초기화

• 한 프로그램은 스택에 약
  64KB 메모리를 할당하고 이를 초기화해야 했음
• 표준적인 방식은 먼저 스택 프로브를 수행해 64KB 메모리를 사용할 수 있는지 확인하는 절차였음
• 이후 스택 포인터에서 65,536을 빼고, 작고 타이트한 루프로 메모리를 초기화하는 방식이 일반적이었음

컴파일러의 과도한 루프 언롤링

• 해당 코드를 컴파일한 컴파일러는 각 바이트를 초기화하는 루프를 생성하지 않았음
• 대신 루프를 65,536개의 개별
  “메모리에 바이트 쓰기” 명령으로 펼쳐서 생성했음
• 각 명령은 4바이트 길이였음
• 결과적으로 64KB 데이터를 초기화하기 위해
  256KB 코드가 필요했음

에뮬레이터 팀의 대응

• 에뮬레이터 팀은 이 함수를 감지하는 특수 코드를 번역기에 추가했음
• 감지된 함수는 동등한 동작을 수행하는
  짧은 루프로 대체되었음
• 이 처리는 원래 프로그램 코드를 그대로 번역하는 대신, 에뮬레이션 중 비효율적인 코드 패턴을 더 간결한 형태로 바꾸는 방식이었음

댓글과 토론