34207


特にCLRは構造体のようなコピーコストの高い機能がありますが、スタックマシンは一般にコピー回数が増えがちかと思います。  
今でこそJITコンパイラが成熟したおかげでこのあたりの技術選択がそこまでクリティカルにはならないと思いますが、コピーコストを抑える意味でもレジスタマシンを採用したほうが自然に思えました。  
実際に、Luaは確か5.0からコピーコストを嫌ってレジスタマシンに再実装したと記憶しています(LuaはTagged
Poinetrのようなハックを嫌ったため即値でさえヘッダを含むとか(うろ覚え))。  
MSや開発者の言質があれば最高ですが、推測でも大変ありがたいのでご意見いただければと思います。


CC BY-SA 3.0
2017-04-22T06:15:23.907
34203
2017-04-22T07:48:21.747
22716
question
.net
何故.NET Framework(CLR)は仮想スタックマシンを採用したのでしょうか？


C#コンパイラーチームのEric Lippertさんが[Why have a
stack?](https://blogs.msdn.microsoft.com/ericlippert/2011/11/28/why-have-a-
stack/)にて次のように発言されていました。

> There are several reasons, but again, it primarily comes down to lowering
> costs. Stack machines are very easy to understand, they are very easy to
> write a compiler front-end for, they are easy to build interpreters for,
> they are easy to build jitters for, and they provide a concise abstraction
> for the common case. The common case is that the result of any particular
> operation is only going to be of interest for a brief period.

様々なコストを加味してのようです。CLRはC#やVBだけでなく、C++/CLIやJ#やF#、PowerShellなど多くの言語からIL生成されることも意識しているようです。またJITコンパイラが解析しやすいという点も含まれているようです。

* * *

詳しくないのですが、レジスタマシンでは構造体を保持できないのでは…その場合、Javaのようにすべて参照型としてGCで管理する必要がありませんか？
勘違いならすみません。


CC BY-SA 3.0
2017-04-22T07:48:21.747
34207
2017-04-22T07:48:21.747
4236
34203
answer