c - logo - assembly language(asl)

¿Por qué los programas no se escriben en ensamblaje con más frecuencia? (30)

Parece ser una opinión generalizada de que la programación de ensamblajes lleva más tiempo y es más difícil de programar que un lenguaje de nivel superior como C. Por lo tanto, parece recomendarse o suponerse que es mejor escribir en un lenguaje de nivel superior por estas razones y por la razón de una mejor portabilidad.

Recientemente he estado escribiendo en el ensamblaje de x86 y me he dado cuenta de que tal vez estas razones no son realmente ciertas, excepto quizás la portabilidad. Tal vez sea más una cuestión de familiaridad y saber cómo escribir bien el ensamblaje. También noté que la programación en ensamblaje es bastante diferente a la programación en un HLL. Tal vez un programador de ensamblajes bueno y experimentado pueda escribir programas con la misma facilidad y rapidez que un programador en C con experiencia en C.

Tal vez sea porque la programación de ensamblajes es bastante diferente de los HLL, y por lo tanto requiere diferentes formas de pensar, métodos y formas, lo que hace que parezca muy incómodo programar para lo desconocido, y así le da su mal nombre para escribir programas.

Si la portabilidad no es un problema, entonces, ¿qué tendría C sobre un buen ensamblador como NASM?

Edición: Sólo para señalar. Cuando escribe en el ensamblaje, no tiene que escribir solo en los códigos de instrucciones. Puede usar macros y procedimientos y sus propias convenciones para hacer varias abstracciones para hacer que los programas sean más modulares, más fáciles de mantener y más fáciles de leer. Aquí es donde está familiarizado con cómo escribir un buen ensamblaje.

¿Por qué? Sencillo.

Compara esto:

for (var i = 1; i <= 100; i++) { if (i % 3 == 0) Console.Write("Fizz"); if (i % 5 == 0) Console.Write("Buzz"); if (i % 3 != 0 && i % 5 != 0) Console.Write(i); Console.WriteLine(); }

con

.locals init ( [0] int32 i) L_0000: ldc.i4.1 L_0001: stloc.0 L_0002: br.s L_003b L_0004: ldloc.0 L_0005: ldc.i4.3 L_0006: rem L_0007: brtrue.s L_0013 L_0009: ldstr "Fizz" L_000e: call void [mscorlib]System.Console::Write(string) L_0013: ldloc.0 L_0014: ldc.i4.5 L_0015: rem L_0016: brtrue.s L_0022 L_0018: ldstr "Buzz" L_001d: call void [mscorlib]System.Console::Write(string) L_0022: ldloc.0 L_0023: ldc.i4.3 L_0024: rem L_0025: brfalse.s L_0032 L_0027: ldloc.0 L_0028: ldc.i4.5 L_0029: rem L_002a: brfalse.s L_0032 L_002c: ldloc.0 L_002d: call void [mscorlib]System.Console::Write(int32) L_0032: call void [mscorlib]System.Console::WriteLine() L_0037: ldloc.0 L_0038: ldc.i4.1 L_0039: add L_003a: stloc.0 L_003b: ldloc.0 L_003c: ldc.i4.s 100 L_003e: ble.s L_0004 L_0040: ret

Son idénticas en cuanto a características. El segundo ni siquiera es ensamblador, pero .NET IL (lenguaje intermedio, similar al código de bytes de Java). La segunda compilación transforma el IL en código nativo (es decir, casi ensamblador), lo que lo hace aún más críptico.

ASM tiene poca legibilidad y no se puede mantener realmente en comparación con los idiomas de nivel superior.

Además, hay muchos menos desarrolladores de ASM que para otros lenguajes más populares, como C.

Además, si utiliza un lenguaje de nivel superior y las nuevas instrucciones de ASM están disponibles (por ejemplo, SSE), solo necesita actualizar su compilador y su antiguo código puede hacer uso de las nuevas instrucciones fácilmente.

¿Qué pasa si la próxima CPU tiene el doble de registros?

Lo contrario de esta pregunta sería: ¿Qué funcionalidad ofrecen los compiladores?

Dudo que pueda / quiera / debería optimizar su ASM mejor que gcc -O3 .

Además de las respuestas de legibilidad, facilidad de mantenimiento, código más corto y, por lo tanto, menos errores de otras personas, y siendo mucho más fácil, agregaré una razón adicional:

velocidad del programa.

Sí, en el ensamblaje puede ajustar el código a mano para utilizar cada ciclo pasado y hacerlo tan rápido como sea físicamente posible. Sin embargo, ¿quién tiene el tiempo? Si escribes un programa C no completamente estúpido, el compilador hará un muy buen trabajo de optimización para ti. Probablemente realice al menos el 95% de las optimizaciones que haría a mano, sin que tenga que preocuparse por realizar un seguimiento de cualquiera de ellas. Definitivamente hay un tipo de regla de 90/10 aquí, donde el último 5% de las optimizaciones terminará ocupando el 95% de su tiempo. ¿Entonces, para qué molestarse?

Bueno, he estado escribiendo mucho ensamblaje "en los viejos tiempos", y puedo asegurarles que soy mucho más productivo cuando escribo programas en un lenguaje de alto nivel.

C es un ensamblador de macros! ¡Y es la mejor!

Puede hacer casi todo lo que puede hacer el ensamblaje, puede ser portátil y, en la mayoría de los casos excepcionales, en los que no puede hacer algo, aún puede usar el código de ensamblaje incorporado. Esto deja solo una pequeña fracción de los programas que absolutamente necesita escribir en ensamblado y nada más que ensamblaje.

Y las abstracciones de mayor nivel y la portabilidad hacen que valga la pena para la mayoría de las personas escribir software de sistema en C. Y aunque tal vez no necesite portabilidad ahora, si invierte mucho tiempo y dinero en escribir algún programa, es posible que no desee limitarse En lo que podrás usar para en el futuro.

Como desarrollador que pasa la mayor parte de su tiempo en el mundo de la programación integrada, diría que el ensamblaje está lejos de ser un lenguaje muerto / obsoleto. Existe un cierto nivel de codificación cercano al metal (por ejemplo, en los controladores) que a veces no se puede expresar de forma tan precisa o eficiente en un lenguaje de nivel superior. Escribimos casi todas nuestras rutinas de interfaz de hardware en ensamblador.

Dicho esto, este código de ensamblaje se envuelve de tal manera que se puede llamar desde el código C y se trata como una biblioteca. No escribimos todo el programa en ensamblaje por muchas razones. Lo primero y más importante es la portabilidad; nuestra base de código se utiliza en varios productos que utilizan arquitecturas diferentes y queremos maximizar la cantidad de código que se puede compartir entre ellos. El segundo es la familiaridad del desarrollador. En pocas palabras, las escuelas no enseñan ensamblaje como solían hacerlo, y nuestros desarrolladores son mucho más productivos en C que en ensamblaje. Además, tenemos una gran variedad de "extras" (elementos como bibliotecas, depuradores, herramientas de análisis estático, etc.) disponibles para nuestro código C que no están disponibles para el código en lenguaje ensamblador. Incluso si quisiéramos escribir un programa de ensamblaje puro, no podríamos hacerlo porque varias bibliotecas de hardware críticas solo están disponibles como C libs. En un sentido, es un problema de huevo / gallina. La gente se aleja del ensamblaje porque no hay tantas bibliotecas y herramientas de desarrollo / depuración disponibles para él, pero las herramientas / libs no existen porque no hay suficiente gente que use el ensamblaje para justificar el esfuerzo de crearlas.

Al final, hay un momento y un lugar para casi cualquier idioma. Las personas usan aquello con lo que están más familiarizados y son más productivos. Probablemente siempre habrá un lugar en el repertorio de programadores para el ensamblaje, pero la mayoría de los programadores encontrarán que pueden escribir código en un lenguaje de nivel superior que es casi tan eficiente en mucho menos tiempo.

El montaje no es portátil entre diferentes microprocesadores.

Estoy aprendiendo ensamblaje en comp org en este momento, y aunque es interesante, también es muy ineficiente para escribir. Tienes que mantener muchos más detalles en tu cabeza para que las cosas funcionen, y también es más lento escribir las mismas cosas . Por ejemplo, una línea simple de 6 líneas para bucle en C ++ puede ser igual a 18 líneas o más de ensamblaje.

Personalmente, es muy divertido aprender cómo funcionan las cosas a nivel de hardware, y me da una mayor apreciación de cómo funciona la computación.

Estoy seguro de que hay muchas razones, pero hay dos razones rápidas que se me ocurren

El código de ensamblaje es definitivamente más difícil de leer (estoy seguro de que también requiere más tiempo para escribir)
Cuando tiene un gran equipo de desarrolladores trabajando en un producto, es útil dividir el código en bloques lógicos y protegerlo mediante interfaces.

He escrito descargas de ensamblador para los chips 6502, Z80, 6809 y 8086. Dejé de hacerlo tan pronto como los compiladores de C estuvieron disponibles para las plataformas a las que me dirigía, e inmediatamente se hicieron al menos 10 veces más productivos. La mayoría de los buenos programadores usan las herramientas que usan por razones racionales.

Hell®, soy un compilador.

Acabo de escanear miles de líneas de código mientras estabas leyendo esta oración. Hojeé millones de posibilidades de optimizar una sola línea tuya utilizando cientos de técnicas de optimización diferentes basadas en una gran cantidad de investigación académica en la que pasarías años. No sentiré ninguna vergüenza, ni siquiera un ligero problema, cuando convierto un bucle de tres líneas a miles de instrucciones solo para hacerlo más rápido. No me avergüenzo de hacer grandes esfuerzos de optimización o de hacer los trucos más sucios. Y si no quieres que lo haga, quizás por un día o dos, me comportaré y lo haré como quieras. Puedo transformar los métodos que estoy usando cuando lo desee, sin siquiera cambiar una sola línea de su código. Incluso puedo mostrarle cómo se vería su código en ensamblaje, en diferentes arquitecturas de procesador y diferentes sistemas operativos y en diferentes convenciones de ensamblaje, si lo desea. Sí, todo en segundos. Porque, ya sabes, yo puedo; y sabes, no puedes.

PD: Por cierto, no estabas usando la mitad del código que escribiste. Te hice un favor y lo tiré.

Hubo un círculo vicioso a medida que el ensamblaje se hizo menos común: a medida que los lenguajes de mayor nivel maduraban, los conjuntos de instrucciones en ensamblador se construían menos para la conveniencia del programador y más para la conveniencia de los compiladores.

Así que ahora, de manera realista, puede ser muy difícil tomar las decisiones correctas sobre, por ejemplo, qué registros debe usar o qué instrucciones son un poco más eficientes. Los compiladores pueden usar heurísticas para determinar qué compensaciones pueden tener la mejor recompensa. Probablemente podamos pensar en problemas más pequeños y encontrar optimizaciones locales que puedan superar a nuestros compiladores ahora bastante sofisticados, pero lo más probable es que en el caso promedio, un buen compilador hará un mejor trabajo en el primer intento que un buen programador probablemente lo hará. Eventualmente, como John Henry, podríamos vencer a la máquina, pero podríamos agotarnos seriamente para llegar allí.

Nuestros problemas ahora también son bastante diferentes. En 1986, estaba tratando de averiguar cómo obtener un poco más de velocidad de los pequeños programas que involucraban poner unos cientos de píxeles en la pantalla; Quería que la animación fuera menos brusca. Un caso justo para el lenguaje ensamblador. Ahora estoy tratando de averiguar cómo representar las abstracciones en torno al lenguaje del contrato y la política del administrador de hipotecas, y prefiero leer algo que se parezca al lenguaje que habla la gente de negocios. A diferencia de las macros de LISP, las macros de ensamblaje no hacen cumplir muchas reglas, por lo que aunque pueda obtener algo razonablemente parecido a un DSL en un buen ensamblador, será propenso a todo tipo de peculiaridades que ganen '' No me cause problemas si escribo el mismo código en Ruby, Boo, Lisp, C # o incluso F #.

Sin embargo, si sus problemas son fáciles de expresar en un lenguaje de ensamblaje eficiente, más poder para usted.

La misma razón por la que ya no vamos al baño afuera, o porque no hablamos latín o arameo.

La tecnología viene y hace las cosas más fáciles y accesibles.

EDITAR - para dejar de ofender a las personas, he eliminado ciertas palabras.

La portabilidad siempre es un problema, si no ahora, al menos con el tiempo. La industria de la programación gasta miles de millones cada año para portar software antiguo que, en el momento en que se redactó, "obviamente" no tenía ningún problema de portabilidad.

Llevo aproximadamente un mes programando en ensamblador. A menudo escribo un fragmento de código en C y luego lo compilo en ensamblador para ayudarme. Quizás no estoy utilizando la potencia de optimización completa del compilador de C, pero parece que mi fuente de C asm incluye operaciones innecesarias. Así que estoy empezando a ver que la conversación sobre un buen compilador de C que supera a un buen programador de ensamblaje no siempre es cierta.

De todos modos, mis programas de montaje son muy rápidos. Y cuanto más uso el ensamblaje, menos tiempo me lleva escribir mi código porque realmente no es tan difícil. Además, el comentario sobre el montaje que tiene poca legibilidad no es cierto. Si etiqueta sus programas correctamente y hace comentarios cuando se necesita una elaboración adicional, debería estar listo. De hecho, el ensamblador es más claro para el programador porque están viendo lo que está sucediendo en el nivel del procesador. No sé de otros programadores, pero para mí me gusta saber qué está sucediendo, en lugar de que las cosas estén en una especie de caja negra.

Dicho esto, la verdadera ventaja de los compiladores es que un compilador puede entender patrones y relaciones y luego codificarlos automáticamente en las ubicaciones apropiadas en la fuente. Un ejemplo popular son las funciones virtuales en C ++ que requieren que el compilador asigne óptimamente los punteros a las funciones. Sin embargo, un compilador se limita a hacer lo que el creador del compilador le permite al compilador hacer. Esto lleva a que los programadores a veces tengan que recurrir a hacer cosas extrañas con su código, agregando tiempo de codificación, cuando podrían haberse hecho de forma trivial con el ensamblaje.

Personalmente creo que el mercado soporta en gran medida los idiomas de alto nivel. Si el lenguaje ensamblador era el único que existía en la actualidad, su programación sería aproximadamente un 70% menos de personas y quién sabe dónde estaría nuestro mundo, probablemente en los años 90. Los idiomas de nivel superior atraen a una gama más amplia de personas. Esto permite un mayor suministro de programadores para construir la infraestructura necesaria de nuestro mundo. Las naciones en desarrollo como China e India se benefician enormemente de lenguajes como Java. Estos países desarrollarán rápidamente su infraestructura de TI y la gente estará más interconectada. Así que mi punto es que los lenguajes de alto nivel son populares no porque produzcan un código superior, sino porque ayudan a satisfacer la demanda en los mercados mundiales.

Lo mismo ocurre con la mayoría de lo que otros han dicho.

En los viejos tiempos antes de que se inventara C, cuando los únicos lenguajes de alto nivel eran COBOL y FORTRAN, había muchas cosas que no se podían hacer sin recurrir al ensamblador. Era la única forma de obtener toda la flexibilidad, poder acceder a todos los dispositivos, etc. Pero luego se inventó C, y casi todo lo que era posible en ensamblaje fue posible en C. He escrito muy poco ensamblado desde entonces. entonces.

Dicho esto, creo que es un ejercicio muy útil para que los nuevos programadores aprendan a escribir en ensamblador. No porque realmente lo usarían mucho, sino porque entonces entiendes lo que realmente está sucediendo dentro de la computadora. He visto muchos errores de programación y código ineficiente de programadores que claramente no tienen idea de lo que realmente está sucediendo con los bits y bytes y los registros.

Lo que C tiene sobre un buen ensamblador de macros es el lenguaje C. Verificación de tipos. Loop construye. Gestión automática de la pila. (Casi) gestión automática de variables. Las técnicas de memoria dinámica en ensamblador son un dolor masivo en el trasero. Hacer una lista enlazada correctamente es simplemente aterrador en comparación con C o mejor aún, foo.insert (). Y la depuración - bueno, no hay competencia sobre qué es más fácil de depurar. HLLs gana las manos ahí abajo.

He codificado casi la mitad de mi carrera en ensamblador, lo que me hace muy fácil pensar en ensamblador. Me ayuda a ver qué está haciendo el compilador de C, lo que, de nuevo, me ayuda a escribir el código que el compilador de C puede manejar de manera eficiente. Una rutina bien pensada escrita en C se puede escribir para producir exactamente lo que desea en el ensamblador con un poco de trabajo, ¡y es portátil! Ya tuve que volver a escribir algunas rutinas asm antiguas en C por razones multiplataforma y no es divertido.

No, me quedo con C y lidiaré con la leve desaceleración ocasional en el rendimiento en comparación con el tiempo de productividad que gano con HLL.

Me encanta la programación en lenguaje ensamblador, pero se necesita más código para hacer lo mismo que en un lenguaje de alto nivel, y existe una correlación directa entre las líneas de código y los errores. (Esto fue explicado hace décadas en The Mythical Man-Month .)

Es posible pensar en C como un "ensamblaje de alto nivel", pero suba unos pasos por encima de eso y estará en un mundo diferente. En C # no piensas dos veces en escribir esto:

foreach (string s in listOfStrings) { /* do stuff */ }

Esto sería docenas, quizás cientos de líneas de código en ensamblaje, cada programador que lo implementara tomaría un enfoque diferente, y la siguiente persona que venga tendría que resolverlo. Por lo tanto, si cree (como lo hacen muchos) que los programas están escritos principalmente para que otras personas los lean, el ensamblaje es menos legible que el HLL típico.

Edición: acumulé una biblioteca personal de código utilizado para tareas comunes y macros para implementar estructuras de control tipo C. Pero llegué a la pared en los años 90, cuando las GUI se convirtieron en la norma. Se estaba gastando demasiado tiempo en cosas que eran rutinarias.

La última tarea que tuve donde ASM era esencial fue hace unos años, escribir código para combatir el malware. Sin interfaz de usuario, por lo que fue todas las partes divertidas sin la hinchazón.

Si un programa de producción promedio tiene 100 000 líneas de código, y cada línea tiene aproximadamente 8-12 instrucciones de ensamblador, eso sería 1 millón de instrucciones de ensamblador.

Incluso si pudiera escribir todo esto a mano a una velocidad decente (recuerde, es 8 veces más código que tiene que escribir), ¿qué sucede si desea cambiar parte de la funcionalidad? ¡Comprender algo que escribiste hace unas semanas de ese millón de instrucciones es una pesadilla! No hay módulos, ni clases, ni diseño orientado a objetos, ni marcos, ni nada. Y la cantidad de código de aspecto similar que tiene que escribir, incluso para las cosas más simples, es, en el mejor de los casos, desalentadora.

Además, no puede optimizar su código tan bien como un lenguaje de alto nivel. Donde C, por ejemplo, realiza un número de optimizaciones insanas porque describe su intención, no solo su código, en el ensamblador solo escribe el código, el ensamblador no puede realizar ninguna optimización digna de mención en su código. Lo que escribes es lo que obtienes, y créeme, no puedes optimizar de manera confiable 1 millón de instrucciones que parcheas y parcheas a medida que las escribes.

Solo puedo responder por qué personalmente no escribo programas en ensamblaje más a menudo, y la razón principal es que es más tedioso hacerlo. Además, creo que es más fácil equivocarse sutilmente sin darse cuenta de inmediato. Por ejemplo, puede cambiar la forma en que usa un registro en una rutina, pero olvide cambiar esto en un lugar. Se ensamblará bien y puede que no lo note hasta mucho más tarde.

Dicho esto, creo que todavía hay usos válidos para el montaje. Por ejemplo, tengo varias rutinas de ensamblaje bastante optimizadas para procesar grandes cantidades de datos, usando SIMD y siguiendo el enfoque paranoico de que "cada bit es sagrado" [cita V.Stob]. (Pero tenga en cuenta que las implementaciones ingenuas de ensamblajes a menudo son mucho peores de lo que generaría un compilador para usted).

Supongo que ASM incluso en x86 (_64) tiene sentido en los casos en los que se gana mucho utilizando instrucciones que son difíciles de optimizar para un compilador. x264, por ejemplo, usa mucho asm para su codificación, y las ganancias de velocidad son enormes.

Un nivel razonable de competencia de ensamblador es una habilidad útil, especialmente si trabaja en cualquier nivel de sistema o programación integrada, no tanto porque tiene que escribir tanto ensamblador, sino porque a veces es importante entender lo que realmente hace la caja. . Si no tiene una comprensión de bajo nivel de los conceptos y problemas del ensamblador, esto puede ser muy difícil.

Sin embargo, en cuanto a escribir realmente mucho código en el ensamblador, hay varias razones por las que no se hace mucho.

Simplemente no hay (casi) necesidad. Excepto por algo como la inicialización temprana del sistema y quizás algunos fragmentos de ensamblador ocultos en las funciones de C o macros, todo el código de muy bajo nivel que una vez se haya escrito en ensamblador puede escribirse en C o C ++ sin dificultad.
El código en lenguajes de nivel superior (incluso C y C ++) condensa la funcionalidad en muchas menos líneas, y existe una investigación considerable que muestra que la cantidad de errores se correlaciona con la cantidad de líneas del código fuente. Es decir, el mismo problema, resuelto en ensamblador y C, tendrá más errores en ensamblador simplemente porque es más largo. El mismo argumento motiva el movimiento a idiomas de nivel superior como Perl, Python, etc.
Al escribir en ensamblador, debe lidiar con cada aspecto del problema, desde el diseño detallado de la memoria, la selección de instrucciones, la selección de algoritmos, el manejo de la pila, etc. Los lenguajes de nivel superior le quitan todo esto, por lo que son mucho más densos. términos de LOC.

Esencialmente, todo lo anterior está relacionado con el nivel de abstracción disponible para usted en ensamblador frente a C o algún otro idioma. El ensamblador te obliga a hacer todas tus propias abstracciones y a mantenerlas a través de tu autodisciplina, donde cualquier lenguaje de nivel medio como C, y especialmente los idiomas de nivel superior, te proporcionan abstracciones fuera de la caja, así como el Capacidad de crear nuevos con relativa facilidad.

Uno de los primeros descubrimientos (lo encontrará en el Mes-Hombre mítico de Brooks, que es de la experiencia en la década de 1960), fue que las personas eran más o menos tan productivas en un idioma como en otro, en líneas de código depuradas por día. Obviamente, esto no es universalmente cierto, y puede romperse cuando se lo presiona demasiado, pero en general se aplica a los lenguajes de alto nivel de la época de Brooks.

Por lo tanto, la forma más rápida de obtener productividad sería utilizar lenguajes donde una línea de código individual hizo más, y de hecho esto funciona, al menos para lenguajes de complejidad como FORTRAN y COBOL, o para dar un ejemplo más moderno C.

$$$

Una empresa contrata a un desarrollador para ayudar a convertir el código en $$$. Cuanto más rápido se pueda producir un código útil , más rápido la empresa puede convertir ese código en $$$.

Los idiomas de nivel superior son generalmente mejores para producir grandes volúmenes de código útil. Esto no quiere decir que el ensamblaje no tenga su lugar, ya que hay momentos y lugares donde nada más lo hará.

Cuando escribe en el ensamblaje, no tiene que escribir solo en los códigos de instrucciones. Puede usar macros y procedimientos y sus propias convenciones para hacer varias abstracciones para hacer que los programas sean más modulares, más fáciles de mantener y más fáciles de leer.

Entonces, lo que básicamente dice es que con el uso experto de un ensamblador sofisticado, puede hacer que su código ASM se acerque cada vez más a C (o de cualquier otro modo, a un lenguaje de bajo nivel de su propio invento), hasta que finalmente esté Tan productivo como un programador de C

Eso responde tu pregunta? ;-)

No digo esto a la ligera: he programado utilizando exactamente un ensamblador y un sistema de este tipo. Aún mejor, el ensamblador podría apuntar a un procesador virtual, y un traductor por separado compiló la salida del ensamblador para una plataforma de destino. Al igual que sucede con la FI de LLVM, pero en sus primeras formas es anterior a la fecha de alrededor de 10 años. Así que hubo portabilidad, además de la capacidad de escribir rutinas para un ensamblador objetivo específico donde se requiere para la eficiencia.

Escribir usando ese ensamblador fue tan productivo como C, y con la comparación con GCC-3 (que estaba disponible en el momento en que participé), el ensamblador / traductor produjo un código que era aproximadamente tan rápido y generalmente más pequeño. El tamaño era realmente importante, y la compañía tenía pocos programadores y estaba dispuesta a enseñar un nuevo idioma a los nuevos empleados antes de que pudieran hacer algo útil. Y teníamos la copia de seguridad de que las personas que no conocían al ensamblador (p. Ej., Los clientes) podían escribir C y compilarlo para el mismo procesador virtual, utilizando la misma convención de llamadas, etc., de modo que se interconectara perfectamente. Así que se sintió como una victoria marginal.

Eso fue con varios años de trabajo en la bolsa desarrollando la tecnología de ensamblador, las bibliotecas, etc. Es cierto que gran parte de esto se convirtió en portátil, si solo hubiera estado apuntando a una arquitectura, entonces el ensamblador de todos los bailes y cantantes hubiera sido mucho más fácil.

En resumen: puede que no te guste C, pero eso no significa que el esfuerzo de usar C sea mayor que el esfuerzo de encontrar algo mejor.

La gente parece olvidar que también existe la otra dirección.

¿Por qué estás escribiendo en Assembler en primer lugar? ¿Por qué no escribir el programa en un lenguaje de bajo nivel?

En lugar de

mov eax, 0x123 add eax, 0x456 push eax call printInt

Podrías escribir

B823010000 0556040000 50 FF15.....

Eso tiene muchas ventajas, usted sabe el tamaño exacto de su programa, puede reutilizar el valor de las instrucciones como entrada para otras instrucciones y ni siquiera necesita un ensamblador para escribirlo, puede usar cualquier editor de texto ...

Y la razón por la que aún prefieres al ensamblador al respecto, es la razón por la que otras personas prefieren C ...

Porque siempre es así: el tiempo pasa y las cosas buenas también pasan :(

Pero cuando escribes un código asm es una sensación totalmente diferente a cuando codificas lenguajes de alto nivel, aunque sabes que es mucho menos productivo. Es como si fueras un pintor: eres libre de dibujar lo que quieras de la forma que quieras sin ninguna restricción (bueno, solo por las características de la CPU) ... Por eso me encanta. Es una pena que este lenguaje se vaya. Pero mientras alguien todavía lo recuerda y lo codifica, ¡nunca morirá!

Revisando estas respuestas, aposté 9/10 de los que respondieron que nunca han trabajado con la asamblea.

Esta es una pregunta antigua que surge de vez en cuando y se obtienen las mismas respuestas, en su mayoría mal informadas. Si no fuera por la portabilidad, yo mismo haría todo en conjunto. Incluso entonces, codifico en C casi como lo hice en ensamblaje.

Como se mencionó anteriormente, la razón para que exista cualquier herramienta es la eficiencia con la que puede funcionar. Como los HLL pueden realizar los mismos trabajos que muchas líneas de código ASM, creo que es natural que otros lenguajes sustituyan el ensamblaje. Y para el violín cercano al hardware: hay ensamblaje en línea en C y otras variantes según el idioma. El Dr. Paul Carter dice en el lenguaje ensamblador de PC.

"... una mejor comprensión de cómo funcionan realmente las computadoras a un nivel más bajo que en lenguajes de programación como Pascal. Al obtener una comprensión más profunda de cómo funcionan las computadoras, el lector puede ser mucho más productivo al desarrollar software en lenguajes de nivel superior como C y C ++. Aprender a programar en lenguaje ensamblador es una excelente manera de lograr este objetivo ".

Tenemos introducción a la asamblea en mis cursos universitarios. Ayudará a aclarar conceptos. Sin embargo, dudo que alguno de nosotros escriba el 90% del código en ensamblador. ¿Qué tan relevante es el conocimiento de ensamblaje en profundidad hoy?

La ventaja de los HLL es aún mayor cuando se compara el ensamblaje con un lenguaje de nivel superior al de C, por ejemplo, Java o Python o Ruby. Por ejemplo, estos idiomas tienen recolección de basura: no hay que preocuparse por cuándo liberar un trozo de memoria, y no hay pérdidas de memoria o errores debido a la liberación demasiado pronto.