지금은 가상화로 퉁칠 수 있습니다.

예전 64비트 초기에 이타늄이 32비트 에물례이팅 하려다가 쫄딱 망했는데. 그때와는 다릅니다.

32비트 앱 메모리 세그먼트 작업 지원을 위한 64비트 메모리 세그먼트 단순화 어쩌고~, 이건 현대의 64비트 운영체제가 32비트 앱 지원을 위해 이미 사용하고 있는 것~ 어쩌고 하는 내용이 있는걸로 봐서 단순 처리 비트수 차이 정도의 수준이면 지금도 CPU가 32비트 모드로 돌아간다거나 하는 게 아니라 그냥 64비트에 끼워맞춰서 돌리는 식인가 싶긴 하네요. 윈도우의 WoW64 호환성 레이어라거나...

윈도우의 호환 레이어의 경우, 이기종(x86-arm) 호환 처리의 경우이면서 비트수까지 서로 다를 때, x86-arm32로 에뮬레이션할 지 아니면 x86-x64(WoW64)-arm64로 변환 및 에뮬레이션할 지 옵션이 있는데(기본값은 후자) 애초에 arm에서도 x86-x64 호환 레이어인 WoW64가 돌아간다는 소리고, 그럼 애초에 64비트OS에서 32비트앱을 돌리는 용도인 WoW64가 하는 일이 하드웨어가 연관된 무언가는 아닐 수도 있지 않나 싶기도 하고요. 근데 이건 잘 모르겠네요.

실제로 굉장히 힘듭니다. ARM과 달리 x86의 경우 하위호환성을 완벽하게 보장하기 위해 AMD64가 기존 x86 베이스 위에 덧붙는 식으로 만들어졌기 때문에 둘을 찢어서 어느 한쪽만 남긴다는게 어려운걸로 압니다.

어려운게 맞긴 합니다만 그보다는 os단에서도 동시에 수정이 있어야 하고 노력대비 얻는 이점이 크지않습니다.

일단 없애는 명령어가 그리 많을수가 없는것이 x86은 호환성을 중시하면서 발전을 해와서 어지간한 명령어나 레지스터들이 전부 하위호환이 됩니다. 없앨수가 없다는거죠.

그럼에도 이제는 저 얼마 안되는것도 손봐야 할만큼 공간이 없는것이 아닌가? 생각 되네요.