뇌피셜을 풀어보자면 그 이유가 별 거 없다고 봐요...

AMD가 64비트 명령어셋인 x86-64 를 만든 시기는 2000년도 전후입니다...

1. CPU는 여전히 단일다이를 싱글코어가 다 차지하던 시절입니다. 트랜지스터를 아껴써야 하는 상황이었습니다.

2. x86-32는 명령어셋 자체의 결함에도 불구하고 클럭과 IPC를 여전히 순조롭게 올리던 시즌이었습니다. 

3. x86 외에도 MMX, SSE, 3D-NOW, 등의 여러 SIMD계열 확장 명령어들이나 넷버스트같은 클럭을 극단적으로 올리는 방식 등이 활발하게 개발되던 시기 입니다. 즉 x86자체의 성능향상에 지장이 있더라도 어차피 높은 성능이 필요한 부분은 SIMD명령어들이 커버해 주리라고 기대했던 시기죠.

때문에...

1. x86-64의 64비트 명령어셋은 기존 32비트 명령어를 그대로 수행할 수 있으면서도 64비트 명령어들이 덧붙는 방식으로 설계 됩니다.

2. 명령어를 덧붙이는 식으로 구성하면서 디코더도 단일 디코더를 확장하는 방식으로 구현 됩니다. 그러니 디코더에 들어갈 트랜지스터가 절약되죠.

3. 결과적으로 x86-64는 기존 x86-32 이래로 유구히 전해져 내려온 쓰레기같은 명령어 구조를 개선하지는 않았습니다. 사실 더 꼬아논 것에 가깝죠.

그리고 시간은 10여년이 흘러 2010년초...  이번에는 ARM이 64비트 명령어셋으로의 도약을 시도 합니다.

ARM이 당면한 전제조건은 격변했습니다.

1. 트랜지스터는 말 그대로 남아 돕니다. 얼마나 남아도냐 하면 모바일에 막 4코어를 때려박고 그런 시대가 왔습니다.

2. 명령어셋이 개떡같아도 클럭/IPC가 쑥쑥 올라가더라는 신화는 10년전에 끝났습니다.  더이상 명령어셋을 개판으로 방치할 여유가 없어졌습니다. (ARM32, 즉 AArch32도 80년대 중반에 개발된 실험적이었던 시도가 많았던 명령어셋이고 x86만큼 쓰레기급은 아니지만 쓸데없는 레거시가 만만찮은 그런 명령어셋입니다. )

3. 2000년대동안 단일코어 IPC향상의 대안이라고 생각했던 방식들의 한계가 뚜렷해 집니다. 넷버스트 망했고 불도저도 망했습니다. SIMD계열 명령어들은 가장 성공한 방식이기는 하지만 기본명령어의 IPC향상과는 별도의 영역을 형성하게 됩니다. 

트랜지스터는 남아도는데 IPC향상에 대한 요구는 더욱 커지고 그에 따라 명령어셋 효율화는 절박해졌습니다. 

디코더의 명령어해석 기능을 32비트와 64비트를 아예 별도로 더 만들어 놓는 게 유리해지는 환경이 조성된거죠.

그리고 실제로도 그렇게 AArch32의 32비트 명령어셋과 AArch64의 32비트 명령어셋은 아예 별개의 세트가 되었습니다.

트랜지스터는 모자라는데 명령어셋 효율화는 애초에 손댈 수조차 없을 지경이었고 IPC향상에 몰빵하지 않아도 그냥 깡설계 내지는 SIMD와 같은 다른 방법으로도 성능향상이 가능하리라는 희망에 차있던 2000년 전후의 x86과는 처한 환경이 전혀 달랐던 겁니다.  

그게 x86의 쓰레기 명령어 구조 해결에 대한 책임을 x86-64에는 물을 수 없는 이유이기도 합니다.