tucuman - ¿Por qué los desarrolladores de microsoft eligieron hacer de.NET una máquina basada en pila?

porque se eligió tucumán (3)

Hoy he encontrado el Desensamblador IL entre las herramientas provistas con VS2008. Intenté desmontar un programa y echar un vistazo al resultado. Los códigos de operación no eran tan difíciles de entender pero una cosa me sorprendió: .NET está basado en pila? Leyendo "Escriba un gran código, volumen II" No obtuve una buena imagen de las máquinas basadas en pila porque son bastante lentas. También son fáciles de implementar, pero no creo que los desarrolladores de MS eligieran este enfoque debido a su simplicidad, ya que todo ese código debe traducirse en código de máquina real para que solo puedan resolver el problema.
¿Puede alguno de ustedes explicar esta extraña elección?

PS :
Publico aquí lo que leí sobre este tema:

13.1.1 Máquinas basadas en la pila Las máquinas basadas en la pila utilizan la memoria para la mayoría de los cálculos, empleando una pila en la memoria para contener todos los operandos y resultados. Los sistemas informáticos que emplean una arquitectura de pila ofrecen algunas ventajas importantes sobre otras arquitecturas:
Las instrucciones son a menudo más pequeñas (cada una consume menos bytes) que las que se encuentran en otras arquitecturas porque las instrucciones generalmente no tienen que especificar ningún operando.
En general, es más fácil escribir compiladores para arquitecturas de pila que para otras máquinas porque convertir expresiones aritméticas en una secuencia de operaciones de pila es muy fácil.
Las variables temporales rara vez se necesitan en una arquitectura de pila, porque la pila en sí sirve para ese propósito.
Desafortunadamente, las máquinas apiladoras también tienen algunas desventajas serias:
Casi todas las instrucciones hacen referencia a la memoria (que es lenta en las máquinas modernas). Aunque los cachés pueden ayudar a mitigar este problema, el rendimiento de la memoria sigue siendo un problema importante en las máquinas de pila.
Aunque la conversión de HLL a una máquina de pila es muy fácil, hay menos oportunidades de optimización que con otras arquitecturas.
Debido a que las máquinas de pila están accediendo constantemente a los mismos elementos de datos (es decir, los datos en la parte superior de la pila), es difícil lograr el paralelismo de instrucciones y tuberías (consulte Escribir Gran Código, Volumen 1 para obtener detalles sobre el paralelismo de instrucciones y tuberías).
Una pila es una estructura de datos que permite operaciones solo en unos pocos elementos limitados de la pila (a menudo llamada la parte superior de la pila y la siguiente en la pila). Con una pila, por lo general, realiza una de estas tres cosas: inserta datos nuevos en la pila, extrae datos de la pila o opera con los datos que se encuentran actualmente en la parte superior de la pila (y posiblemente los datos que se encuentran debajo).

13.1.1.5 Máquinas de pila del mundo real
Una gran ventaja de la arquitectura de pila es que es fácil escribir un compilador para tal máquina. También es muy fácil escribir un emulador para una máquina basada en pila. Por estas razones, las arquitecturas de pila son populares en máquinas virtuales (VM), como la Máquina Virtual de Java y el intérprete de código p de Microsoft Visual Basic. Existen algunas CPU basadas en pila del mundo real, como una implementación de hardware de la máquina virtual Java; sin embargo, no son muy populares debido a las limitaciones de rendimiento del acceso a la memoria. No obstante, comprender los conceptos básicos de una arquitectura de pila es importante porque muchos compiladores traducen el código fuente de HLL en una forma basada en pila antes de traducir al código de máquina real. De hecho, en el peor de los casos (aunque raro), los compiladores se ven obligados a emitir código que emula una máquina basada en pila cuando compila expresiones aritméticas complejas.

EDITAR: Acabo de encontrar un artículo en el blog de @ EricLippert respondiendo la pregunta y confirmando la respuesta de @Aarón

La razón por la que CIL se basa en la pila es porque no fue diseñado para ser un conjunto de instrucciones que apunta a una máquina virtual. Es una etapa intermedia de compilación.

El CLR es más un compilador + tiempo de ejecución en lugar de una máquina virtual como la JVM. El diseño CLR no intenta proporcionar un buen rendimiento del código de bytes interpretado. En su lugar, intenta verificar y compilar un código de byte de alto nivel para el código de máquina en tiempo de ejecución.

Tendrías que preguntar a los desarrolladores de Microsoft. Pero supongo que el problema de rendimiento no era su preocupación principal. La mayoría de las aplicaciones de Windows no están limitadas por la CPU, ni siquiera por la I / O, ya que pasan la mayor parte de su tiempo esperando a que el usuario haga clic en un botón. Sin embargo, tener una arquitectura que les permitiera implementar nuevos idiomas fácilmente era una prioridad.

Tenga en cuenta que solo porque la representación intermedia esté basada en la pila no significa que el código de máquina generado esté basado en la pila. A medida que el código se convierte del formulario intermedio al código de máquina, se compila básicamente, lo que permite optimizaciones locales.

Una vez que lo bueno de usar una representación intermedia basada en la pila es que no estás atado a ninguna arquitectura específica.

Imagínese si hubieran decidido utilizar un sistema basado en registros teóricos como su forma intermedia. ¿Cuántos registros deben elegir? 8? ¿dieciséis? 64? Si su procesador de destino tiene más registros reales que el formulario intermedio, entonces ha perdido posibilidades de optimización. Si su objetivo tiene menos registros reales que el intermedio, entonces sus optimizaciones son contraproducentes porque esos registros se guardan en la memoria de todos modos.

Incluso en las CPU actuales tiene una gran diferencia compilando hasta x86 vs x64, sin mencionar las arquitecturas alternativas (ARM) o las arquitecturas futuras.

Para algo como esto es bueno que lo hayan mantenido en la forma más simple y luego confíen en la optimización durante la generación del código final para que coincida con el hardware real.