Por qué es aún una buena idea aprender Ensamblador.

Nóta:
Este artículo fué originalmente escrito pensando en el lenguaje ensamblador para procesadores Intel Pentium. Sin embargo, como los argumentos presentados por el autor se aplican también en mainframes, pensamos que es relevante publicarlo en en esta página web también.

Advertencia:
Bixoft convirtió "Por qué es aún una buena idea aprender Ensamblador" en un documento HTML con el permiso del autor original para republicarse. También le hicimos algunos cambios menores. Con todo esto, aún aplican los derechos de autor del Sr. Hyde al documento a continuación.

Contacto:
El Sr. Hyde gustosamente aceptará sus comentarios, observaciones, etc. envíe un e-mail a Randall hyde.

Este documento contiene las siguientes secciones:

Un excelente código va mas allá de lo ordinario
La clave es la eficiencia
Practique sus habilidades
Aprenda el Lenguaje Ensamblador
El Ensamblador no está muerto
Domine las instrucciones de bajo nivel
Conclusión

Un excelente código va mas allá de lo ordinario

El mundo está lleno de estudios que esbozan los desastres de ingeniería de software. Casi todos los programadores han trabajado en algún projecto que incluye código "punto menos que estelar", el código fuente era difícil de leer y mantener. En raras ocasiones, algunos programadores tienen la oportunidad de trabajar en un sistema bien diseñado, una verdadera obra de arte que los inspira y usualmente provoca admiración, y exclaman, "¡Este es verdaderamente un gran código!"

Claramente, los ingenieros profesionales de software deberían esforzarse para alcanzar este nivel de grandeza en todos su código. Pero la verdadera pregunta es, " ¿Qué hace excelente al código?" No se llega a escribir un gran código con el solo "cumplir las especificaciones". Es verdad, en las condiciones actuales de desarrollo, algunos podrían creer que el solo hecho de cumplir las especificaciones hace que una aplicación sobresalga, ya que muchos projectos de desarrollo fracasan para cumplir los objetivos de su diseño original.

Sin embargo, en otras áreas, la grandeza es raramente definida al hacer lo esperado exitosamente; la grandeza es definida por realizar algo mas allá de lo esperado. Los ingenieros de Software no deberían conformarse con menos que un gran código - deberían ir más allá y por encima de los estándares convencionales para el desarrollo.

La clave es la eficiencia

Debido a que la grandeza es una virtud con múltiples facetas, un artículo tan corto como este, no puede tratar de cubrir todos los componentes de una gran pieza de código. En su lugar, este artículo describirá un componente de escribir un gran código, que ha caido en el olvido en los últimos años, al mismo tiempo que las computadoras han incrementado en capacidad y poder: La eficiencia.

Cualquiera que haya estado en esta industria alrededor de una década o más, conoce perfectamente este fenómeno: las máquinas son exponencialmente mas poderosas por unidad de costo, sin embargo, los usuarios no perciben estas mejorías en las aplicaciones que ellos compran. Por ejemplo, mientras los procesadores de palabra son claramente más rápidos hoy, que lo que eran hace 21 años, no son 16,384 veces más rápidos como la Ley de Moore [1] sugeriría. Desde luego parte del problema es que algo del poder de procesamiento adicional se emplea para soportar las nuevas características (tales como el desplegado a nivel de bits), pero una gran parte de la razón de que los usuarios del software no vean incrementarse la rapidez, es porque muchos de los programadores de hoy, no se toman el tiempo para escribir un código eficiente, o simplemente no saben como escribir software rápido.

Los míseros períodos otorgados al desarrollo de programas, no dan tiempo suficiente para desarrollar un código eficiente; También es verdad que muchos programadores actuales, han crecido con ordenadores rápidos, cuya velocidad encubre pobres hábitos de codificación, y es así como muchos de estos programadores nunca han tenido que aprender como escribir un código rápido.

Desafortunadamente, cuando el desempeño de las aplicaciones es punto menos que óptimo, estos programadores generalmente no saben como corregir los problemas con su código. Frecuentemente mencionan cosas como "la regla del 90-10," o "Yo usaré un analizador de código para corregir los problemas de desempeño ", pero la verdad es que no saben realmente como mejorar el desempeño de sus aplicaciones con bajo rendimiento. Solamente mencionan, "¡ya encontraré un mejor algoritmo!" Sin embargo, el encontrar y plasmar el algoritmo, si realmente existe, es otra cosa completamente distinta.

La mayoría de las veces Ud. puede lograr un rendimiento más elevado al mejorar la implementación de un algoritmo existente. Un científico en computación, puede alegar que una mejoría constante en rendimiento no es tan buena, como por ejemplo, al ir de un algoritmo con rendimiento O(n^2) a uno con desempeño O(n lg n), pero la verdad es que la mayor parte del tiempo un factor constante de mejoría de dos o tres veces, aplicada a través de un programa, puede hacer la diferencia entre una aplicación práctica y otra que es simplemente muy lenta para usarse confortablemente. Y es exactamente este tipo de optimización con la cual la mayoría de los programadores modernos tienen poca experiencia.

Desafortunadamente, el escribir un código eficiente es una habilidad; una, que debe ser practicada para aprenderla y otra, que debe ser practicada para mantenerla. Los programadores que nunca practican esta habilidad, nunca serán capaces de aplicarla el dia que ellos descubran que su cóodigo esta corriendo muy lentamente. Aún si el programador ha dominado la habilidad de escribir un código eficiente, debe practicarla constantemente. Asi que hay dos razones por las cuales algunos programadores no escriben (un gran y) eficiente código hoy: ellos nunca aprendieron como escribir código eficiente en primer lugar, o ellos han permitido que sus habilidades de desarrollo se atrofien al punto que no son capaces de escribir más un código eficiente.

Practique Sus Habilidades

Para programadores quienes han permitido simplemente que sus habilidades desmayen por falta de uso, la solución es obvia; practique codificar eficientemente, aún cuando el projecto no lo requiere en lo absoluto. Esto desde luego no significa que el ingeniero practicante, debe sacrificar los tiempos destinados para el projecto, o que deje de realizar un código fácil de entender y mantener, u otros atributos importantes, en favor de la eficiencia.

Lo que si significa, es que el Ing. en desarrollo de sistemas debe mantener en mente la eficiencia mientras diseña o implementa el código. El programador debe elegir concientemente una implementación menos eficiente, por sobre una implementación más eficiente, basado en decisiones económicas o de ingeniería, más que simplemente codificar lo primero que le viene a la mente. La simple consideración de implementar un código diferente (y posiblemente más eficiente), es todo lo que se necesita para producir un gran código. Despues de todo, algunas veces la implementación más eficiente no es más difícil de crear que la ineficiente. Todos los ingenieros experimentados pueden necesitar múltiples opciones de las cuales elegir.

Desafortunadmente, los tiempos irreales otorgados al desarrollo, han llevado a muchos ingenieros profesionales a desechar la revisión y la implementación minuciosa. El resultado es que muchos programadores profesionales han abandonado el hábito de escribir un gran código. Afortunadamente, este proceso es fácil de reversar al emplear metodologías de desarrollo efectivas, tales como la consideración de múltiples algoritmos y sus implementaciones, tan frequentemente como sea posible.

Aprenda el Lenguaje Ensamblador

¿Y en primer lugar, qué hay del programador que nunca ha aprendido a codificar eficientemente? ¿Como aprende uno a implementar eficientemente una aplicación? Desafortunadamente las escuelas técnicas y universidades, intencionalmente toman la actitud de que si Ud. elige un buen algoritmo, no tiene que preocuparse de la implementación de ése algoritmo. La mayoría de los estudiantes salen de sus cursos de estructuras de datos y algoritmos, con la actitud de que si Ud. puede lograr una unidad de contante de mejoría (esto es O(1)), Ud, realmente no ha logrado nada, y cualquier intento de mejorar es una pérdida de tiempo.

Los avances en arquitectura de los ordenadores han exacerbado este problema - por ejemplo, Ud. podría escuchar a un programador decir, "Y si este programa necesita ser un poco más rápido, solo esperen un año o un poco más y el CPU será dos veces más rápido; no hay de que preocuparse". Y esta actitud, probablemente más que cualquier otra, es el por qué el rendimiento del código no crece a la par con el desempeño del CPU.

Con cada nueva aplicación, el programador escribe el código mas lento de lo que debería correr en cualquier CPU que ellos usen, creyendo que en el futuro, la mejoría en el rendimiento del CPU solucionará sus problemas. Desde luego, para el momento que el CPU es lo suficientemente rápido para ejecutar su código, el programador ha "mejorado" el programa, y ahora depende de una nueva versión del CPU para "mejorarlo" de nuevo. El ciclo se repite casi invariablemente, con el rendimiento del CPU sin darse abasto para satisfacer las demandas del software, hasta que finalmente, la vida del software llega a su fin, y el programador comienza de nuevo el ciclo con una aplicación distinta.

La verdad es que si es posible escribir programas eficientes que se ejecuten eficientemente en procesadores contemporáneos. Los programadores estaban haciendo grandes cosas con su código en los dias en que sus aplicaciones corrían en ocho bits a 5 MHZ en PCs 8088 (o aún más atrás en procesadores de mainframe corriendo en sub-megaherz); Las mismas técnicas que ellos usaron para exprimir hasta el último bit de desempeño de esos ordenadores de bajo poder, es la clave para el alto rendimiento de las aplicaciones actuales. Asi, que ¿como lograron ellos un desempeño razonable en procesadores de tan bajo poder? La respuesta no es un secreto - ellos comprendieron como operaban esencialmente los "fierros" y escribieron su código de acuerdo a eso. Ese mismo conocimiento esencial del hardware, es la clave para codificar eficientemente hoy en dia.

Frecuentemente, Ud. escucha a los viejos programadores comentar que el software realmente eficiente esta escrito en lenguaje ensamblador. Sin embargo, la razón la razón de que los programas sean eficientes, no es porque el lenguaje otorgue propiedades mágicas de eficiencia a ese código - es perfectamente posible escribir software ineficiente en lenguaje ensamblador-. No, la razón real del porque los programas en lenguaje ensamblador tienden a ser más eficientes que los programas escritos en otros lenguajes, es simplemente porque el lenguaje ensamblador forza al programador a considerar como el hardware opera con cada instrucción que ellos escriben. Y esto es la llave para aprender a codificar eficientemente - manteniendo la mirada atenta en la capacidad de bajo nivel de la máquina.

Esos mismos viejos programadores que reclaman que los programas realmente eficiente está escrito en lenguaje ensamblador, también ofrecen otro consejo igualmente válido - si quiere aprender a escribir un gran código en un lenguaje de alto nivel, aprenda a programar en lenguaje ensamblador.

Este es un consejo muy bueno. Despues de todo, los compiladores de alto nivel trasladan las intrucciones de alto nivel a código máquina de bajo nivel. Asi que si conoce el lenguaje ensamblador para su máquina en particular será capaz de correlacionar las instrucciones del lenguaje de alto nivel con el lenguaje de máquina que el compilador genera. Y con este entendimiento, Ud. será capaz de escoger las mejores instrucciones del lenguaje de alto nivel basado en su conocimiento de como convierten los compiladores estas instrucciones a código de máquina.

Frecuentemente, los programadores de lenguaje de alto nivel eligen ciertas instrucciones del lenguaje, sin conocimiento alguno del costo de ejecución de esas instrucciones. El aprender el lenguaje ensamblador forza al programador a aprender los costos asociados con varias contrucciones de alto nivel. Asi que, aún si el programador realmente nunca escribe aplicaciones en lenguaje ensamblador, ese conocimiento, hace que el programador esté conciente de los problemas que causan ciertas secuencias ineficaces, asi que ellos las evitan en su código.

El aprender el lenguaje ensamblador, asi como cualquier otro lenguaje, requiere de un esfuerzo considerable. El problema es que el lenguaje ensamblador en si mismo, es engañosamente simple. Ud. puede aprender las 20 o 30 instrucciones que se encuentan comúnmente en las aplicaciones en solo unos cuantos dias. Ud. inclusive puede aprender a encadenar varias instrucciones de esas para solucionar problemas, de la misma manera que solucionaría esos mismos problemas, con otro lenguaje en unas cuantas semanas.

Desafortunadamente, este no es el tipo de conocimiento que un programador de lenguaje de alto nivel encontrará lo suficientemente útil al intentar escribir código eficiente de alto nivel. Para alcanzar los beneficios del conocer el lenguaje ensamblador, un programador tiene que aprender a pensar en lenguaje ensamblador. Solo entonces, tal programador puede escribir código de alto nivel muy eficiente, mientras piensa en ensamblador y escribe instrucciones de lenguaje de alto nivel. Aunque el código escrito de esta manera es grande realmente, hay un ligero problema con este acercamiento - que toma un esfuerzo considerable alcanzar este nivel. Esa es una de las razones por la cuales tal código es excelente - porque muy pocos practicantes son capaces de producirlo.

El Ensamblador No Está Muerto

Desde luego, el lenguaje ensamblador desarrolló una mala reputación en todos los 90's. Avances en tecnología del compilador, mejoras en el desempeño del CPU, y la "crisis del software" todos conspiraron para sugerir que el ensamblador era un lenguaje "muerto", que no se necesitaba más. Como el lenguaje ensamblador era un poco mas difícil de aprender que los lenguajes tradicionales de alto nivel, los estudiantes (¡y los maestros!) gustosamente abrazaron estos nuevos lenguajes rápidamente asimilables, abandonando el difícil-de-aprender ensamblador, en favor de lenguajes de cada vez más alto nivel.

El único problema fue que con el olvido del lenguaje ensamblador es que asi como su popularidad se desvaneció, también lo hizo el gran porcentaje de programadores que entendían las ramificaciones en el bajo nivel, de las aplicaciones que ellos estaban escribiendo. Esos programadores quienes clamaban que el lenguaje ensamblador ya había muerto, ya sabían como pensar en lenguaje ensamblador, y como aplicar el pensamiento de bajo nivel a su código de alto nivel; en efecto, gozaron los beneficios del lenguaje ensamblador mientras escribían lenguaje de alto nivel. Sin embargo, cuando la nueva oleada de programadores se abrieron camino en el ambiente, lo hicieron sin los beneficios de haber escrito varias aplicaciones en ensamblador, y la eficiencia de las aplicaciones comenzó a declinar.

Aunque sería tonto reclamar que los programadores comenzaran a escribir aplicaciones comerciales en lenguaje ensamblador, hoy es claro, que la desaparición de la popularidad del lenguaje ensamblador ha tenido un gran impacto en la eficiencia del software moderno. Para reversar esta tendencia, tiene que suceder una de estas dos alternativas: Los programadores deben empezar a estudiar el lenguaje ensamblador, o ellos deben obtener ese conocimiento a bajo nivel de alguna otra manera.

El aprendizaje del lenguaje ensamblador aún permanece como la mejor manera de aprender la organización fundamental de la máquina. Esos programadores quienes se esfuerzan en dominar el lenguaje ensamblador, llegan a ser de los mejores programadores de lenguaje de alto nivel en estos tiempos. Su habilidad para elegir instrucciones apropiadas de código eficiente del más alto nivel, su habilidad para leer código de alto nivel desensamblado, y detectar errores nefastos en un sistema, y su conocimiento de como opera todo el sistema en su totalidad, los eleva a ellos a estaturas legendarias entre sus compañeros de trabajo. Estos son los programadores a los que todos van cuando tienen preguntas de como implementar algo, Estos son los ingenieros que se ganan el respeto de todos a su alrededor. Esos son los programadores que todos tratan de emular. Estos son los programadores que escriben un gran código.

Si el conocimiento del lenguaje ensamblador, ayuda a hacer grandes programadores, la pregunta obvia es "¿Por qué no hay más programadores que aprendan ensamblador?" Parte del problema es el prejuicio: Muchos instructores de escuelas técnicas y universidades que enseñan lenguaje ensamblador, comienzan su curso con un comentario como "Realmente nadie necesita conocer esto, y ustedes nunca lo van a usar, pero este programa lo requiere, asi que vamos a batallar las próximas semanas estudiando este material". Despues de cuatro años de este tipo de actitud de sus profesores, no es sorprendente que los estudiantes realmente no quieran tener nada que ver con utilizar el lenguaje ensamblador para programar.

Aún asi, una vez que es obvio para el codificador que los verdaderos programadores son aquellos que han dominado el lenguaje ensamblador, Ud. podría preguntar, ¿por qué no hay más programadores dispuestos a aprender este conocimiento tan valuable?. El único problema, es que tradicionalmente la mayoría de los programadores se han topado con la dificultad de dominar el lenguaje ensamblador. El ensamblador es radicalmente diferente de los lenguajes de alto nivel, asi que el aprender el lenguaje ensamblador, es casi tanto como volver a empezar a programar.

Para alguien que intenta aprender ensamblador, invariablemente parece que nada de su conocimiento de los otros lenguajes pudiera ser de mucha ayuda. Frecuentemente, un ingeniero aprendiendo ensamblador se frusta con el hecho de que ya saben como lograr los objetivos en otro lenguaje de alto nivel, pero simplemente no se figuran como lograr lo mismo con el ensamblador. Para muchos programadores, el cambio de "pensar en un lenguaje de alto nivel" a "pensar en lenguaje ensamblador" constituye una barrera infranqueable.

Como instructor de lenguaje ensamblador por más de una década en la Universidad de California, tenía pleno conocimiento de los problemas que los estudiantes tienen para hacer la transición del paradigma de lenguaje de alto nivel al paradigma de programar a un bajo nivel.

A principios de los 90's, Microsoft proporcionó una solución con la introducción del Microsoft Macro Assembler (MASM) v6.0 - la inclusión de estructuras de control de alto nivel en el traductor del lenguaje ensamblador. Mientras estas instrucciones no son realmente lenguaje ensamblador, ellas proporcionan una agradable transición de los tradicionales e imperativos lenguajes de alto nivel, al ensamblador. Un programador puede continuar usando instrucciones como IF, WHILE, y FOR mientras aprende otros aspectos de los programas en lenguaje ensamblador. Esto le permite al programador aprender gradualmente el ensamblador, en lugar de tener que aprenderlo todo de una vez.

Igualmente, para el High-Level Assembler (HLASM) de IBM, se cuenta con varias bibliotecas macro que implementan la misma funcionalidad desde hace varios años.

Domine las Instrucciones de Bajo Nivel

Desde luego, un programador no se puede llamar asimismo programador de lenguaje ensamblador, hasta que haya dominado las instrucciones de bajo nivel equivalentes. Aún asi, estas estructuras de control de alto nivel, proveen un puente excelente entre los lenguajes de alto nivel y el lenguaje ensamblador, permitiendo a los estudiantes utilizar su conocimiento de programación de alto nivel, para aprender el lenguaje ensamblador.¡Ahh!, también hay unos cuantos textos apropiados que enseñan la programación en lenguaje ensamblador usando este enfoque de estructuras de control de alto nivel que proporciona el MASM (o el HLASM).

Otro problema con la transición de alto nivel a un bajo nivel, es que la mayoría de lenguajes de alto nivel proporcionan grandes bibliotecas que manejan tareas mundanas como entrada/salida, conversiones numéricas, y operaciones de encadenamiento. Un gran problema al que se enfrentran los programadores en ensamblador principiantes, es que ellos típicamente necesitan la habilidad de introducir y obtener cantidades numéricas o realizar conversiones numéricas a cadenas (y viceversa), para escribir y probar programas muy simples. Desafortunadamente la mayoría de los sistemas de desarrollo en lenguaje ensamblador, le dejan la responsabilidad al programador de proporcionar esta funcionalidad para sus aplicaciones. Esto presenta una situación muy sui-generis: es difícil aprender el lenguaje ensamblador sin estas funciones, ni tampoco puede codificar tales funciones, hasta que aprenda a programar en ensamblador.

Estas piedras en el camino evitan efectivamente dominar el lenguaje ensamblador a la mayor parte de los programadores, con excepción de los más determinados. De esta manera, durante los 90s y principios de este siglo, el uso del ensamblador continua menguándose. Al ver la declinación en la eficiencia y calidad del software, percatándome que se relaciona con el bajo uso del ensamblador, comencé una cruzada a mediados de los 90s para motivar a los programadores a aprender a programar en lenguaje ensamblador.

El primer gran logro que tuve, fue la liberación a mediados de los 90s de la edición electrónica de El Arte del Lenguaje Ensamblador. Este libro, junto con el uso de la correspondiente biblioteca UCR Estandar para programadores de Lenguaje Ensamblador en 80x86, redujo el esfuerzo necesario para el aprendizaje del lenguaje ensamblador. Decenas de miles de programadores han aprendido a programar en ensamblador usando esto libro de texto y el conjunto de bibliotecas de rutinas complementarias.

El único problema con la edición electrónica de El Arte del Lenguaje Ensamblador y las Bibliotecas UCR Estándar para programadores de lenguaje ensamblador para máquina 80x86, es que se hicieron obsoletas al momento de la aparición en el Internet, porque enseñaban al lector como crear aplicaciones DOS en 16-bits (su aparición casi coincidió con la liberación de Windows 95, que fué uno de los últimos clavos en el ataúd de programación de 16 bits.

Aún en la cruzada, empecé a trabajar en un completamente nuevo ensamblador de Alto Nivel (HLA), una nueva versión de el Arte del Lenguaje Ensamblador, y un nuevo conjunto de bibliotecas de rutinas basadas en HLA para 32-bit. Este esfuerzo culminó con la publicación de la edición de El Arte del Ensamblador (AoA) en el 2003. A la fecha, miles y miles de programadores han adoptado entusiastamente esta nueva manera de aprender el lenguaje ensamblador, usando AoA, HLA, y la Biblioteca Estándar de HLA.

Aunque el Arte del Lenguaje Ensamblador y el HLA han logrado incrementar el número de programadores en ensamblador dia a dia, la solución que ellos proporcionan es para la siguiente generación de programadores.

¿Que hay acerca de los actuales programadores, que han perdido la oportunidad de aprender el lenguaje ensamblador cuando estuvieron en la escuela y lograron dominar los conceptos de organización de la máquina antes que la realidad de los projectos les robaran el tiempo para desarrollar el conocimiento necesario para escribir un gran código? La pregunta es, "¿La organización de la máquina puede ser efectivamente enseñada a programadores profesionales sin enseñarles el lenguaje ensamblador simultáneamente?"

Mientras está perfectamente claro que el aprendizaje del lenguaje ensamblador es el mejor consejo que yo le puedo dar a alguien interesado en escribir un gran y eficiente código, también estoy convencido que alguien puede estudiar la organización de la máquina SANS ensamblador y aún aprender como escribir un mejor código. Quizás su código no será tan bueno como el de quienes dominen el lenguaje ensamblador, pero será mejor que el software que han escrito desprovistos de este conocimiento.

Más importantemente, mientras es difícil vender la idea de aprender el lenguaje ensamblador a la generación actual de programadores (dos décadas de propaganda anti-ensamblador se han asegurado de esto), la mayor parte de los programadores se dan cuenta que si solo "aprendieran un poco más acerca de como trabaja las capas fundamentales del hardware", ellos serían capaces de escribir un mejor código. Asi que lo que se necesita es una colección de materiales que enseñen representación de datos, organización de la memoria, elementos de arquitectura de la computadora, como funciona el proceso de entrada/salida y la correspondencia entre las instrucciones de programación del lenguaje de alto nivel.

Esto es, enseñarles todas las cosas que tendrían que aprender cuando aprenden el lenguaje ensamblador, con la sola excepción de dominar la programación en ensamblador. Recientemente, me he comenzado a enfocar en este grupo, trabajando en libros como Escriba Gran Código, Primer Volumen: Entendiendo la Máquina (Write Great Code, Volume One: Understanding the Machine), un libro sobre la organización de la máquina que no enseña a programar en ensamblador específicamente. Mientas que alguien que estudia la organización de la máquina podría no escribir un gran código como alguien que se ha tomado el tiempo de dominar el lenguaje ensamblador, mi esperanza es que esos que nunca considerarían aprender el lenguaje ensamblador, podrían interesarse en rescatar un libro como Escriba un Gran Código, y aprenda a codificar mejor, aunque no sea un gran código.

Conclusión

Para escribir un gran código, se requiere escribir un código eficiente. El escribir un código eficiente requiere la elección de buenos algoritmos y la implementación buena de esos algoritmos. Las mejores implementaciones van a escribirlas aquellos que hayan dominado el lenguaje ensamblador, o aquellos que entiendan completamente la implementación de bajo nivel de las instrucciones de alto nivel que ellos han seleccionado. Esto no significa que regresaremos a los dias cuando las mayores aplicaciones comerciales eran escritas por completo en lenguaje ensamblador. Sin embargo, para reversar la tendencia de los programas corriendo cada vez más lento, aún con los CPUs corriendo cada vez más rápido, se requieren programadores que comiencen a consideras las implicaciones de bajo nivel del código que ellos han escrito.

De esta manera, aún si Ud. nunca pretende escribir la más sencilla línea de código en ensamblador, el aprender el lenguaje ensamblador y el aprender a pensar en lenguaje ensamblador, es una de las mejores cosas que Ud. puede hacer para aprender como codificar mejor.

Nota 1:
La ley de Moore establece que la tecnología de los semiconductores se duplica en capacidad o desempeño cada 18 meses.
La ley de Moore no dice nada acerca del rendimiento. Solo menciona que el número de transistores se duplica cada dos años. Un ARTIFACT de las progresiones de la Ley de Moore ha sido que el desempeño hasta hace poco, ha crecido a la par.

Acerca del Autor:
Randall Hyde es el autor de las recientes publicaciones "Write Great Code" y "The Art of Assembly Language" (ambos de No Starch Press), una de las publicaciones más altamente recomendadas para el lenguaje ensamblador para procesadores tipo Intel. Existen similares recursos comparables para HLASM y los procesadores de mainframe.

Esta página es un miembro de WebRing. Te invitamos a ver la lista de sitios que apoyan el mainframe. lista of sitios relacionados con mainframes.		Los Dinos no estan muertos. Ellos están vivos y bien y viviendo en centros de cómputo a tu alrededor. Hablan en lenguas y esparcen magias extrañas con computadoras. ¡Ten cuidado con el dino! Y por si acaso estás esperando la extincón final de estos dinos: ¡recuerda que los dinos dominaron el mundo por 155 millones de años!
Los Dinos y otros anacronismos [ Unete ahora \| Ring Hub \| Al azar \| << Anterior \| Siguiente >> ]

Ir a Un Excelente Código Va Mas Allá de lo Ordinario.
Ir a La Clave es la Eficiencia.
Ir a Practique Sus Habilidades.
Ir a Aprenda el Lenguaje Ensamblador.
Ir a El Ensamblador No Está Muerto.
Ir a Domine las Instrucciones de Bajo Nivel.
Ir a Conclusión.

Abajo está los logos de nuestros patrocinadores y logos de los estándares de la web a los que se adhiere este sitio.