2009-04-16 9 views
5

En mi universidad, la clase de Programación de ensamblaje (x86 y MIP) está llegando a su fin.¿De qué maneras puede administrar proyectos de lenguaje ensamblador a gran escala?

He disfrutado mucho mi trabajo de montaje y realmente me gustaría seguir trabajando con él. Uno pensaría que tener que hacer todo solo sería un lastre, pero descubrí que hay un nivel de transparencia que no obtengo con los lenguajes de nivel superior.

Las cosas generalmente funcionan como yo las esperaba, porque ejecuté el código de máquina para que ocurrieran. No hay magia

Sin embargo, en la escuela el programa de ensamblaje más largo que escribí tenía quizás 2-3 páginas.

Hace poco leí sobre Roller Coaster magnate siendo escrito por un único desarrollador, in assembly.
alt text http://i.d.com.com/i/dl/media/dlimage/15/06/92/150692_large.jpeg

No puedo entender cómo alguien podría mantener un proyecto tan grande en el montaje.

En este momento estoy luchando por dar el salto de programas de ensamblaje de 2-3 páginas a algo más de una escala. ¡Incluso en mi calculadora Ti-83, la gente ha escrito clones de Mario/Zelda en el ensamblaje que deben ser tremendamente complejos!

Tiene que haber algunas mejores herramientas, IDEs y métodos para gestionar grandes proyectos de ensamblaje x86 que lo hacen, al menos, algo fácil de mantener.

¿Qué son?

Respuesta

2

Conozco personas que trabajan con ensamblador (no intel). Han construido una macro biblioteca extensa para que puedan usarla casi como si fuera un lenguaje de alto nivel.

Para crear algo así como una macro biblioteca, comience de manera simple. Al agrupar construcciones de uso frecuente en una sola macro. Eventualmente, podrás crear una funcionalidad más compleja.

2

No es realmente la respuesta a su pregunta, pero en muchos escenarios del mundo real, las aplicaciones se escriben en un lenguaje más alto utilizando las expresiones comunes a ese idioma, y ​​solo utilizan un poco de lenguaje ensamblador donde las necesidades de rendimiento o hardware. Este es probablemente el único enfoque sensato para proyectos reales, porque el lenguaje ensamblador simplemente no es tan productivo como otros lenguajes, en términos de hacer que la computadora haga más por cada hora que se pasa programando.

Dicho esto, todas las herramientas y técnicas para gestionar un proyecto en cualquier otro idioma se aplican por igual al lenguaje ensamblador. Source Control, TDD, especificaciones del proyecto, nombres significativos para identificadores, separación de preocupaciones, patrones de diseño orientados a objetos (puede tener un diseño orientado a objetos sin un lenguaje orientado a objetos) se aplican igualmente al lenguaje ensamblador como a C# o PHP

+0

"nombres significativos para identificadores" A menos que mi comprensión de lo que es el lenguaje ensamblador está muy lejos (que muy bien podría ser) ¿no se refieren directamente a las ubicaciones de memoria y registros de CPU? ¿Cómo se obtienen nombres significativos de eso? – Davy8

+0

Es raro usar direcciones de memoria. En general, el ensamblador los vincula a variables. –

+0

ah, no sabía que podía dar nombres de variables en el ensamblado – Davy8

1

Siempre hice lo mismo que en idiomas de alto nivel. Escríbelo en módulos que están vinculados entre sí para formar el tiempo de ejecución.

2

El único proyecto moderno escrito completamente en el conjunto que sé si es FASM (mi ensamblador favorito).

Algunos ensambladores admiten construcciones de alto nivel, y si el motor de macro es bueno, puede escribir uno propio. Personalmente encuentro esto inútil; si quiero construcciones de alto nivel y para entender lo que hago, utilizo C o C++. (No creo que sean buenos lenguajes para gestionar grandes proyectos).

Solo uso ensamblaje cuando sea necesario o para aprender.

Si desea escribir un proyecto de montaje, tenga en cuenta que:

  • Probablemente no habrá mucha gente que quiere que le ayude con su proyecto, incluso les resulta interesante. Pocas personas, como el ensamblado y su código, deben ser muy bien comentados si espera que alguien lo entienda.
  • El montaje no es portátil. Incluso para cambiar de PC de 32 bits a 64 bits, básicamente tendrá que volver a escribir todo.
  • El argumento "ensamblar es más rápido" ya no se sostiene.
5

programas de montaje a gran escala son administrados al igual que cualquier otro programa - así se repartió bloques funcionales con clara interfaces. Como está trabajando en ensamblaje, sus interfaces estarán limitadas a elementos en el archivo de registro o la pila. En definitiva, se trata de tener un buen diseño plan antes de la implementación real. Debe tener claridad sobre qué escribir y cómo escribirlo.

Dicho esto, si le gusta el ensamblaje, hay otra manera de poder disfrutar de su pasión sin escribir el código ensamblador: puede escribir en C o C++ y ver cómo se compila el código para ensamblar. Luego, escriba lo mismo de una manera diferente y entienda cómo eso cambia el ensamblaje. Como resultado, pronto podrá pensar como un compilador y escribir un código altamente óptimo.

De cualquier manera, saber cómo funcionan las cosas en el montaje finalmente lo hará un mejor programador.

3

Macros, funciones y bibliotecas. Lleva años desarrollar su propio sistema desde cero, así que busque los recursos del ensamblador x86 y apóyese en los demás: todavía hay muchas personas que realizan el desarrollo de ensamblaje activo para PC.

Un miembro activo de la comunidad de montaje es Steve Gibson, que tiene un montón de enlaces a buenos recursos para programación en ensamblador aquí:

http://www.grc.com/smgassembly.htm

2

Además de lo ya mencionado, que debería mencionar literate programming; Escribí una aplicación que estaba en el orden de 20KLOC de ensamblado ARM (no es enorme, pero tampoco es insignificante), y encontré que estructurar el código con noweb es extremadamente útil.

Esto me permitió dividir el código en pequeñas piezas conceptuales, incluso cuando varias piezas en realidad tenían que combinarse/desenrollarse/etcétera por motivos de rendimiento. También hizo mucho más fácil para otros programadores entender lo que yo había escrito, particularmente las razones por las cuales tomé ciertas decisiones sutiles (por ejemplo, decidir qué operando debería ir primero en una multiplicación basada en el tamaño esperado de los operandos).

Cuestiones relacionadas