Wasm, 스택 머신이라 부르기엔 뭔가 부족하다?

게시물에서는 Wasm이 스택 머신으로 알려져 있지만, 실제로는 레지스터 머신에 가깝다고 분석한다. 기술적으로 보면, 스택 머신은 `dup`, `swap`과 같은 스택 조작 연산을 통해 데이터 재사용(Data Reuse)을 효율적으로 처리해야 한다. 하지만 Wasm은 이러한 연산이 부족하여, 컴파일러가 공통 부분식 제거(Common Subexpression Elimination)와 같은 최적화를 수행하는 데 제약이 따른다. 이러한 특성은 Wasm이 단순한 표현식 평가에 적합하도록 설계되었음을 시사한다.

댓글에서는 Wasm의 스택 기반 설계가 SSA(Static Single Assignment) 형태의 바이트코드를 위한 직렬화 형식(Serialization Format)으로 채택되었다고 설명한다. 특히, 네트워크를 통해 코드를 전송해야 하는 Wasm의 특성상, 스택 기반 코드가 레지스터 기반 코드보다 압축 효율(Compression Efficiency)이 높다는 점이 강조된다. 이러한 설계는 Wasm이 JIT 컴파일러를 통해 레지스터 머신으로 변환될 것을 전제로 한다.

논의에서는 JVM과 CPython의 스택 머신 구현 방식을 비교하며, Wasm과의 차이점을 부각한다. JVM은 `load` 및 `store` 명령어를 사용하여 지역 변수(Local Variables)에 접근하지만, 계산 과정에서는 `dup` 및 `swap`과 같은 스택 조작 연산을 주로 사용한다. CPython 역시 `SWAP` 명령어를 통해 스택을 조작한다. 반면, Wasm은 이러한 스택 조작 연산이 제한적이어서, 컴파일러가 최적화(Optimization)를 수행하는 데 어려움이 있다.

게시물에서는 Wasm의 스택 머신 특성이 최적화에 미치는 영향과 함께, 향후 발전 방향에 대한 논의가 이루어진다. Wasm은 SSA 형태의 바이트코드를 위한 직렬화 형식으로 설계되었으며, JIT 컴파일러를 통해 레지스터 머신으로 변환된다. 또한, Wasm의 스택 기반 설계는 코드 압축에 유리하다는 장점이 있다. 하지만, 스택 조작 연산의 부재(Lack of Stack Manipulation)는 최적화에 제약을 가하며, 향후 Wasm 생태계의 발전에 영향을 미칠 수 있다.