"Motivos principales por los que enseño a desarrollar #videojuegos en #ensamblador en la Universidad de Alicante. Las clases son de 3º y 4º curso de los Grados en Ingeniería Informática e Ingeniería Multimedia. También explico los motivos para elegir #Amstrad CPC como máquina de trabajo y ensamblador #Z80 en vez de un PC moderno y x86/x86_64."
#6#4 Interesante punto de vista, aunque discrepo un poco. Con la informática, no sé muy bien por qué, pero sucede mucho un purismo en plan "sólo está bien hecho si es a bajo nivel". Me la voy a ganar pero da igual, es mi opinión. Por ejemplo, le tengo manía a C++, la única ventaja que tiene es la velocidad de ejecución, todo lo demás me parece antediluviano. Si ir más lejos, cada vez que quieres usar una librería de terceros tienes que montar un circo para compilarla y desplegarla. En mi vida me ha tocado usar bibliotecas muy específicas para cálculos matemáticos, algoritmos, etc. y ha sido siempre un horror. Simplemente podemos comparar eigen con scipy para python. Aún no entiendo la manía de definir siempre tipos de datos especiales que hacen lo mismo que un puto integer de 32 bits. Ahora que ya me he quejado, vuelvo al tema. Ensamblador es para el día a día absurdo, impráctico. Como ejercicio para aprender, sin ninguna duda maravilloso, pero con la potencia de cálculo que…...
Porque si se va al carajo el mundo puedes volver a crear un ordenador desde cero. Cuatro instrucciones para gobernar el nuevo mundo: load, store, sub y jump. Y si me apuras, puedes combinar load y store en una sola.
En mi curro teníamos una rutina en ensamblador heredada desde hace 30 años ...no veáis eluefo que pasamos cuando decidimos dejar de usarla porque nadie sabía muy bien qué hacía
Cada año se celebra un concurso de videojuegos de Amstrad CPC donde sus alumnos participan junto con otros programadores. Ayer en el canal de twitch de Juanje estuvieron dándoles un repaso a los participantes de este año y es bastante impresionante lo que hacen los chicos en sólo un mes.
Seguramente en unos días subirá el video a YouTube youtube.com/c/JuanjeJuega
#1 pues cada día nos cuesta más encontrar ingenieros de bajo nivel de cualquier tecnología: ni electrónicos, ni programadores ni nada. Estamos acostumbrados a trabajar con abstracciones a alto nivel y cosas que hace 20-30 años eran super básicas ahora son totalmente desconocidas para las nuevas generaciones.
El problema es quién inventará la siguiente generación de microprocesadores (o de cualquier otra tecnología) si ninguno d e los actuales recién graduados está ni remotamente interesado en el proceso, ni se les da los conocimientos para hacerlo.
#4 Interesante punto de vista, aunque discrepo un poco. Con la informática, no sé muy bien por qué, pero sucede mucho un purismo en plan "sólo está bien hecho si es a bajo nivel". Me la voy a ganar pero da igual, es mi opinión. Por ejemplo, le tengo manía a C++, la única ventaja que tiene es la velocidad de ejecución, todo lo demás me parece antediluviano. Si ir más lejos, cada vez que quieres usar una librería de terceros tienes que montar un circo para compilarla y desplegarla. En mi vida me ha tocado usar bibliotecas muy específicas para cálculos matemáticos, algoritmos, etc. y ha sido siempre un horror. Simplemente podemos comparar eigen con scipy para python. Aún no entiendo la manía de definir siempre tipos de datos especiales que hacen lo mismo que un puto integer de 32 bits. Ahora que ya me he quejado, vuelvo al tema. Ensamblador es para el día a día absurdo, impráctico. Como ejercicio para aprender, sin ninguna duda maravilloso, pero con la potencia de cálculo que tiene cualquier chip hoy en día, no hay ninguna razón práctica para usarlo directamente. Además de que un compilador va a optimizar mucho más que tú a mano. Con respecto a lo que comentas de los recién graduados, no es tan importante, el que lo necesite puede aprender despues. ¿Cuántos graduados acaban trabajando en Intel o similares? Cuatro gatos, la mayoría van a hacer web, angular, react o lo que esté de moda en el momento. Dicho de otra forma, como ejercicio teórico-intelectual está genial saber optimizar una caché, cómo funciona un flip-flop o resolver interbloqueos en un sistema operativo. Como aplicación al mercado laboral, no te va a valer para nada. Eso me hace pensar que a lo mejor habría que hacer dos carreras, una más técnica y otra más teórica.
#5. Pero es que además sin ensamblador no habría compiladores como C o C++. El compilador tiene una parte que puede estar escrito en C, C++, Java o lo que sea que es la parte que interpresa el código fuente de un lenguaje de alto nivel. Pero la parte del compilador que hace la conversión desde el código fuente a código objeto (el código fuente ya compiliado) convierte ese código directamente a código ensamblador.
#6 Que si, que muy bien trabajar en alto nivel. Yo lo hago. Pero a tu punto de vista le falta lo que apunta #4.
El tema es que a bajo nivel están programados por ejemplo los compiladores, máquinas virtuales o intérpretes. Si nadie estudia seguir desarrollando estos compiladores de bajo nivel, los lenguajes de alto nivel dejan de evolucionar. Y lo que es peor, que para las máquinas (hardware) hace falta conocimientos a un nivel aún más bajo.
No se trata de teoría, también hay práctica. Hay mucho trabajo de esto y es tan necesario como el otro. Otra cosa es que tu vayas a hacer una página web en ensamblador. Eso no lo hace nadie normal, por muy eficiente que pudiera ser.
#11 Puedes hacerlas todas con sub y complemento a 2, y un flag de acarreo. Multiplicar y dividir no erá muy eficiente, pero bueno. Por ejemplo add sería:
ADD dirA, dirB y guardarlo en dirC:
LOAD null --> Posición de memoria inicializada con 0
SUB dirA --> Posición de memoria del valor A
STORE temp
LOAD dirB
SUB temp
STORE dirC
Ah, si alguien se quiere entretener hay un juego muy chulo llamado nandgame.com/ que consisten en construir un ordenador desde cero con puertas lógicas. Luego ya pasas a ensamblador y coma flotante.
Y pensar que antes se hacía con código máquina, en las tarjetas perforadas. Esos decían que los que usaban el ensamblador (ese lenguaje de alto nivel) ya no sabían nada...
#6 No se trata tanto de "sólo está bien hecho si es a bajo nivel", sino de "sólo está bien hecho si quien lo hizo entiende qué pasa a bajo nivel".
Un ejemplo sencillo: uno de los ejercicios de una entrevista de trabajo que hice consistía en convertir una función en javascript que era O(n²) a O(n). La solución que esperaban era obvia, y la saqué correctamente. Pero en realidad seguía siendo O(n²) por el sencillo motivo de que lo que "había que hacer" era utilizar un diccionario para así eliminar uno de los bucles internos. El problema es que, por debajo, un diccionario es, o bien O(n), o bien O(sqrt(n)) según use una lista o un árbol, pero en esa función concreta, en cada pasada podía, o leer un dato, o escribirlo, con lo que si era un árbol, lo que ahorrabas al leer te lo gastabas al balancearlo tras escribir, y si era una lista, estabas igual que antes.
Si no sabes cómo van las cosas "bajo el capó", no te enteras de estos detalles y no entiendes por qué, si has reducido tu función de O(n²) a O(N), sigue tardando más o menos lo mismo.
#9 El problema del ensamblador que nunca te cuentan en realidad no tiene que ver con el ensamblador en sí mismo; el problema que no te cuentan es que no escribes en ensamblador, escribes en ensamblador PARA windows, escribes en ensamblador PARA linux, y, en general, escribes en ensamblador PARA un determinado sistema operativo.
Ese "PARA" es el que, en realidad, arrastra todos los problemas; o, dicho, con otras palabras, el verdadero problema de escribir en ensamblador no es el ensamblador en sí mismo, sino el contexto, es decir, el sistema operativo, en el que escribes ese ensamblador. Porque es con ese contexto con el que realmente te vas a tener que pelear, principalmente buscando la información que necesitas para poder crear un programa compatible con ese sistema operativo. No concibo peor infierno que buscar información para saber cómo crear un programa en ensamblador PARA Windows, especialmente si esa búsqueda de información la intentas realizar entre la información proporcionada por la propia Microsoft.
En definitiva: el problema no es el ensamblador, es el sistema operativo con el que te tienes que pelear para escribir en ensamblador.
#23 Si haces la tabla igual al número de elementos a insertar, necesitas más memoria, pero a cambio ganas el O(1) en escritura/acceso. Si la función hash está bien balanceada, o usando directamente un id. Ese sería el caso extremo donde siempre tienes O(1).
#24 OJO: no es "la tabla igual al número de elementos a insertar", sino "igual al número de POSIBLES elementos a insertar" (o sea, la potencia de dos más cercana "por arriba" al número de elementos a insertar). Sin embargo, el problema que le veo es que entonces las colisiones serán bastante comunes. Por otro lado, si utilizas un ID simplemente, ya no tienes un diccionario sino un array...
#26 Ahí tienes razón, al final he hecho un array . A lo que me refiero es si puedes estimar de forma más o menos acertada el número de elementos a insertar y reducir las colisiones con un hash bien balanceado, tienes casi siempre O(1). Pero también te doy la razón de que no es fácil hacer esto. Con las colisiones puedes incluso hacer un rehash que salte a una nueva posición o incluso otra tabla hash en cada colisión, en vez de usar una lista. Al final tienes casi siempre O(1). Pero depende del caso concreto.
#27 Uf... entiendo lo que quieres decir, pero no lo veo... Fíjate que si el hash es pequeño (por ejemplo, 8 bits), las colisiones serán muy habituales. En cambio, si el hash es más grande (por ejemplo, 32 bits), el tamaño para conseguir un acceso O(1) sería inmenso (4GB*tamaño de cada entrada), con lo que no sería práctico.
Al final, buscar el hash en la lista de hashes del diccionario sigue siendo O(n) si es lineal, u O(sqrt(n)) si usas un árbol (recuerda que tienes primero que localizar el hash, y luego buscar entre todos los elementos con el mismo hash).
Por supuesto, a menos que me esté perdiendo algo, claro... que tampoco es que yo sea un experto en estas cosas
#28 No si razón tienes. Hace falta mucha memoria para sacar O(1) si indexas los hashes en un array. No suelo usar grandes tablas hash sino pequeñitas, por eso no le he dado mucha importancia. Tampoco soy ningún experto.
#7 Hoy ya no sirve programar en ensamblador para amd64, las CPUs tienen microcode y no valen para una mierda la mitad de las cosas.
Es más, el compilador va a optimizar mejor que tu pero de pleno.
Ese ensamblador de la 370 que lo primero que te dicen es que si no tienes la secuencia de cabecera, te cargas el timesharing y van a tener que llamar a alguien que lo arregle. Y estas aconojanado cuando corres tus programas de clase simplemente para probar si estas sumando bien 2+2... .
#15 Pues para mi ingeniero no es saber ensamblador. Es saber hacer programas escalables, mantenibles, robustos, ... con un código modificado por centenerares de programadores durante años
#2 Existen los descompiladores para estas cosas... no te saca los fuentes tal cual fueron hechos (porque ni tienen los nombres de variables, ni te va a dar las cosas exactas tal y como fueron escritas), pero si te traduce de ensamblador a un lenguaje de más alto nivel. Que teniendo en cuenta optimizaciones y demás, el c (o ponga aquí su lenguaje de programación favorito) que te genera no va a ser muy bonito precisamente, pero al menos más sencillo para entender, sobre todo si no manejas el código ensamblador de esa máquina.
#21 Salvo que te dediques a hacer drivers o a programar a tan bajo nivel, normalmente, todo ese PARA ni se te debería ocurrir hacerlo en ensamblador. En ensamblador escribe rutinas de cálculo o cosas así muy concretas y aisladas que quieras acelerar, todo lo que sea interactuar con un SO deberías hacerlo usando las APIs de ese SO, que pa eso están...
#35 Un ingeniero es el que tiene la capacidad para hacer lo uno y lo otro. Que por mucho que sepas escalar, si te ponen a desarrollar un driver para controlar un sistema industrial único, empotrado y aislado no dejas de ser igual de ingeniero que el otro...
#5 Esas IAs que generan código para trasladarlo a Python, C/C++ y otros ya podrían hacerlo en ensamblador, sería la programación más eficiente... supuestamente.
#6con la potencia de cálculo que tiene cualquier chip hoy en día, no hay ninguna razón práctica para usarlo directamente.
¿La eficiencia, que es la base implícita del existir de toda máquina no es suficiente razón? no es el usarlo directamente, es que usar compiladores que compilen a otro lenguaje, es absurdo, los demás lenguajes son sólo traductores con pérdidas de eficiencia, la IAs generadoras de código harán desaparecer todos los lenguajes que no sean lenguaje máquina, quedando sólo el lenguaje máquina y el lenguaje humano, esto sería lo más lógico.
#10 es más sencillo que eso, incluso. Sin el bajo nivel no puedes hacer un Port de us SO, que te permite cambiar de contexto y hacer el switch de las tareas. Gestión de memoria, pila, Program Counter, acumulador....
Yo trabajé varios años en ensamblador, y llegué a hacer un SO en tiempo real muy simple pero efectivo (todavía está en producción hoy día), Port incluido, para la empresa que trabajaba, en ensamblador y C. Te da una idea muy clara de cómo funciona el proveedor y como optimizar procesos.
El sistema central de Iberia Cargo y British Airways Cargo están programados en ensamblador. Y se sigue evolucionando.
Un show verles programar, enlazar con colas de mensajes y demás.
#6 Tocho perdonado. Y estoy de acuerdo en la conclusión: debería haber diferentes no ya carreras pero sí especialidades, unas centradas en la técnica y otras centradas en el uso práctico del software.
#12 también se pueden generar todas las instrucciones aritméticas con puertas NAND. Pero esto nos llevaría a plantearnos para qué vamos a implementar con NAND un sumador con acarreo, por ejemplo, si internamente el procesador ya hace esta abstracción. En esencia pasa lo mismo con los lenguajes de alto nivel sólo que se pierde eficiencia ya que la abstracción conlleva una generalización. Cada lenguaje de programación tiene su ámbito de aplicación y no dudo que siempre habrá programadores especializados en aquellos que se requieran en su campo. No creo que lleguen a faltar programadores de bajo nivel, estarán más cotizados eso sí, pero con la ingente cantidad de ingenieros y técnicos que hay y con toda la información que tenemos disponible es improbable que lleguen a faltar especialistas en cualquier campo.
#31 no es por meterme, bueno si, pero es fácil hacer un hashmap o(1) (amortizado) sin necesidad de reservar un montón de memoria, simplemente doblando su capacidad cuando superas el factor de carga, es lo q hace java por defecto y seguramente Javascript también.
Qué tiempos aquellos en los que por no poder hacerme con un libro de ensamblador del Z80 ni con las revistas de Microhobby con el curso, aprendí nociones básicas por mi mismo con el manual del ZX Spectrum +2, donde venía el juego completo de instrucciones, y lo que aprendí sobre cómo es un ordenador en la única asignatura de informática que hay en la carrera que estudié.
Solo pude llegar a hacer un editor de textos que daba la opción de "encriptar" lo escrito en mi viejo y oxidado Spectrum. Pero lo disfruté como un niño.
Me parece adorable que ahora un profesor se dedique a enseñar eso en sus clases. Me parece básico, por mucho que algunos os empeñeis en no reconocerlo.
#6 La potencia de cálculo de cualquier procesador de hoy en día es enorme,pero cuando tu software está corriendo, por ejemplo, en una "nube", cada ciclo de ejecución te cuesta dinero. Saber ensamblador te sirve para entender qué código está generando tu compilador del lenguaje X de alto nivel y aprender que construcciones del lenguaje generan código más eficiente para tu problema.
Es un recurso que es para usarlo puntualmente en determinados puntos críticos, pero no está de más saberlo.
#33. '...Es más, el compilador va a optimizar mejor que tu pero de pleno...'
¿Adivina por qué? Precisamente por lo que comento en #7. Los ingenieros que desarrollan compiladores en principio conocen bien las caracteristicas de las especificaciones de las CPUs que sus compiladores sorpotan y cuando pasan el código fuente (convenientemente interpretado y troceado) a la parte del compilador que "compila" se crea el código objeto ensamblándolo teniendo en cuenta todo lo atractivo y relevante que puedan ofrecer las nuevas CPUs. Es decir, el lenguage ensamblador sigue siendo imprescindible, y ya si nos pasamos a microcontroladores tipo Arduino es más que relevante. Estoy de acuerdo en que las nuevas CPUs de Intel y AMD hoy en día puedan contener internamente incluso bloatware :
También te digo que para crear un buen compilador no se necesitan ni de lejos todas las nuevas características e instrucciones que puedan incorporar las nuevas CPUs, tanto por temas de compatibilidad entre Intel y AMD como por temas de economía y tiempo. Por poner un ejemplo, el set de instrucciones "3DNow" de los AMD K6-2 de finales de los 90 en su momento tuvieron muy poco soporte en compilares populares. Y con el enlace de arriba más de lo mismo, si las CPUs de Intel empiezan a traer características contenidas en los chips de silicio pero hay que pagar a los de Intel por poder activarlas y utilizarlas muchos compiladores directamente no soportarán esas nuevas características, si es que se tratase de características programables y no "cajas negras", claro.
#6 hay una cosa que dices con la que no estoy de acuerdo.
No siempre es más rápido el código que genera un compilador que el que puedes hacer a mano.
De hecho , en la libc y la stl de c++ hay código en ensamblador para ciertas funciones.
C y C++ se consideran por muchos como bajo nivel e incluso he oído decir que es ensamblador de alto nivel, al idealizar la máquina.
Pero el tema es que no siquiera c,y c++ llegan a poder abstraerse o idealizar una CPU al 100% por ejemplo las instrucciones vectoriales de una CPU.
Si tuvieras que hacer uso de una convolución en ensamblador x86 hay una instrucción para hacerla vectorizada, sin embargo los compiladores , no son tan inteligentes como para entender que ese bucle es una convolución,(les falta el contexto).
Por otro lado si te apoyas en una librería y compilada , no sabrá si puede alinear los datos en memoria y usar las instrucciones de copia que se introdujo creo que en peintiun IV ...
Hay un papel bastante viejo, que quería comparar c, ensamblador y Pascal, en cuestión de eficiencia, y salía que el codigo más eficiente era el ensamblador después el de c y después el de Pascal.
Pero eso era en la primera versión de código , les pidieron hacer modificaciones al programa , para validar que pasaría en un desarrollo normal.
El de compilador , no solo costaba cada vez más mantenerlo, sino que se fue volviendo más lento y el de c paso a ocupar la primera posición.
Después introdujeron restricciones de tiempo a la hora de poder hacer las modificaciones, es decir les pedían una modificación y solo podían hacerla en x horas, y ahí Pascal también acabo pasando a c.
De aquí se pueden sacar conclusiones, pero una de ellas es que a largo tiempo , si es mejor trabajar en un lenguaje de alto nivel, aunque sea solo porque podremos gastar más tiempo en optimizarlo , pero que ciertas partes del.codigo que sabes que solo se tocaran una vez,o muy muy pocas,pero que se ejecuten continuamente, compensara hacerlo en ensamblador....
Justo lo que hace libc y la stl.
#10 no es cierto que los compiladores estén programados en bajo nivel, de hecho hay una fase que suele demostrar la madurez del compilador ( bootstraping )en si mismo que es cuando puedes compilar el codigo de tu compilador usando el mismo. globalwikionline.com/detial/en/Bootstrapping_(compilers)
#6 es muy probable que un compilador optimice mas que muchos programadores si te lo compro en parte:
- los programadores los hay muy buenos
- compiladores los hay muy tontos
- muchas veces se programa con clases que son muy genericas que tienen todo tipo de codigo superfluo para el uso que realmente necesitas de esa clase y el compilador eso no te lo optimiza...
- alguien tiene que hacer el compilador que es lo que dice #4, de todas maneras #4 no hacen falta tantos programadores a bajo nivel por lo que no es gran problema que no haya tantos..
#20 para hacer una tortilla hay que romper los huevos si o si... hay mucho programdor que cree llamando a dameHuevosparaTortilla() no se ha roto ningun huevo.... y si que lo ha roto
#29#28 ambos teneis razon depende del caso si hace falta velocidad el diccionario tendria que tener un hash que evite colisiones al maximo, un O(1) seria un array con indice. Pero depende de la necesidad y es aqui donde esta el debate hoy en día se programa usando diccionarios que son muy genericos que a veces no tienes manera de hacerlo mas adecuado para ti con un hash mas amplio o menos segun necesidades de velocidad o memoria.
#4 También es cada día más difícil encontrar programadores de alto nivel, tienen más salidas laborales y su vida es más cómoda y sencilla.
Las empresas que diseñan microprocesadores son grandes corporaciones con dinero saliéndoles por las orejas. Que paguen cincuenta mil euros anuales más por programador y que los capten y formen recién salidos de la Universidad
#6 pero y lo feliz que queda el profesor no teniendo que aprender nada nuevo y con tentando a los 4 frikis intelectuales, eso no lo cuentas
Realmente lo que aprendan en la carrera, los módulos o lo que sea es absurdo, lo único importante es aprender a programar mentalmente luego ya aprenderás los idiomas que quieras, te certificará etc etc
Y esto es como cuando te obligaban a leer los tochos infumables con 16 años, creo que es más fácil enseñar a la gente a programar "cosas bonitas" que motiven que a quien le guste el quijote ya se esfuerza el sólito
#6 Hay una utilidad práctica más, derivada de que mucha gente no opina igual, al menos en parte
En la mayoría de entrevistas que tienen mis estudiantes, haber hecho un juego en ensamblador es un activo muy valorado. La mayoría de ellos me comentan que suele ser lo primero por lo que se interesan y les preguntan. En muchos casos, ha resultado ser motivo de que los contraten.
Y respecto a que ensamblador no se usa, resulta que una proporción no despreciable de estudiantes ha terminado haciendo cosas directamente en ensamblador. Tengo varios de ellos en empresas de robótica programando microcontroladores en ensamblador. Algunos están en nvidia de estancia aprendiendo ensamblador de las tarjetas gráficas. Tengo un grupo en ARM que están optimizando rutinas de multiplicación de matrices. Y, como no podía ser de otra manera, tengo a unos cuantos trabajando en compiladores que se ocupan de diseñar lo que el compilador debe producir como salida. De estos últimos, hay bastantes que están siendo contratados ahora mismo para arquitecturas RISC V, en las que hay mucho que hacer todavía con los compiladores.
El mercado laboral es muy diverso, y las necesidades reales también. No creo que estos trabajos sean los más demandados, pero tampoco son residuales. Son un nicho, como otro cualquiera. Eso sí, un nicho donde se cobra bien, porque cada vez hay menos oferta de trabajadores.
Muy a menudo todos caemos en la trampa de pensar que nuestro entorno de conocimiento es representativo del global. Lo cierto es que siempre hay mucho más allá de lo que conocemos :).
Conozco 10 tipos de personas: quienes saben ensamblador y los que no
Quienes saben ensamblador, suelen opinar que entienden mejor la máquina y los conceptos fundamentales. Gracias a esto, suelen programar mejor en cualquier nivel y asientan mejor los nuevos conocimientos, sobre explicaciones más ajustadas a la realidad. No suelen criticar ensamblador, y ven con buenos ojos su aprendizaje, por los beneficios globales de entendimiento, más que por su uso directo potencial.
Quienes no saben ensamblador no pueden ver todo esto, debido simplemente a que lo desconocen. Suelen pensar en ensamblador como algo difícil, innecesario o incluso arcaico. Suelen asociarlo únicamente a optimización, y refuerzan con ello su carácter innecesario. Es habitual que critiquen la enseñanza/aprendizaje de ensamblador: suelen preferir lenguajes de alto nivel, y argumentar que son más útiles en el día a día o el trabajo. Les suele contrariar o molestar la opinión de quienes saben ensamblador, y suelen rechazarla.
Moraleja extrapolada: ensamblador te hace criticar menos y ser más feliz
Y ahora en serio, dos cosas al respecto:
1. Cambiando ensamblador y sus propiedades por cualquier conocimiento básico X, seguramente pase lo mismo.
2. Hasta la fecha, todos los mejores profesionales programadores que conozco son del tipo 1: saben y valoran ensamblador. La mayoría no lo usa en su día a día (de forma directa), pero valora el conocimiento que tiene gracias a él.
#56 libc y cualquier librería estándar tiene que utilizar un lenguaje de menos nivel porque necesita proveer al lenguaje conviertas funcionalidades como entrada/salida o llamadas al sistema. En C hay trozos de libc en ensamblador como en Python hay trozos de C.
Y el resto creo que te basas en un conocimiento algo anticuado. Hoy en día los compiladores son capaces de reconocer ciertos bucles y convertirlos en instrucciones vectoriales y muchas otras optimizaciones que antes eran impensables. En el 99.9% de los casos el compilador va a generar mejor código ensamblador que un humano para un procesador moderno.
#48 La conocía, pero no me gusta porque Subleq necesita tres direcciones, con lo cual al final un programa ocupa más en memoria porque load, store, jmp y sub sólo utilizan una dirección. Al final no deja de ser una monstruoinstrucción
Que es la que da acceso al kernel.
Por otro lado lo que afirmas es una sobresimplificacion, el compilador no es capaz ni siquiera de transformar los objetos de manera que no se penalice la caché.
Mira la charla de Mike acton
#6 hombre, programar en ensamblador te enseña como funciona esa arquitectura. Y eso es algo bastante básico. No hace falta que te dediques a diseñar procesadores, pero en una ingeniería deberías aprender cómo funcionan diferentes arquitecturas de procesador.
#67 para hacer la llamada al sistema de ioctl necesitas ejecutar la instrucción ensamblador llamada syscall. La función en C del mismo nombre necesita al menos tener un fragmento de ensamblador que ejecute esa instrucción. No es por optimización si no por necesidad.
Y un compilador no optimiza objetos si no secuencias de instrucciones. Hay investigación sobre eso, sobretodo en Haskell, pero aún estamos a años de que los compiladores de C/C++ puedan hacer optimizaciones tan complejas.
Los procesadores hoy en día tienen pipelines de ejecución tan complicadas (por ejemplo pueden decidir ejecutar instrucciones en otro orden) que no sale a cuenta intentar escribir prácticamente nada en ensamblador a no ser que estés escribiendo un driver o un dispositivo empotrado.
#6 Alguien tiene que saber cómo funcionan los ordenadores, y no usar el framework de moda.
Esta claro que siquieres salir al mercado rápido necesitas usar frameworks que te dan un montón de cosas hechas, pero trabajo con desarrolladores que no saben nada de sistemas, e ingenieros que tienen que decidir que hardware se compra que creen que saben hacer pruebas de rendimiento y no saben.
Mi más cores en un ordenador tiene que ser mejor ni en alto nivel tiene que ser necesariamente más fácil según que tarea. En un grado en informática hay que salir sabiendo lo suficiente de bajo nivel, aunque luego no se vayan a utilizar. Y de todas maneras saber que pasa por debajo ayuda a hacer las cosas mejor.
Te enseñan a programar en lo que sabe programar tu profesor, que lleva sin mirar por la ventana a ver qué pasa en el mundo exterior desde hace 30 años.
Con la escusa de "aprendiendo lo básico es importante".
Lo mismo pasa con compartir ordenador y puestos de laboratorio para "incentivar el trabajo en equipo"
Mediocridad aristoacadémica de bigote y naftalina y recortes
#39 Es que ese es el problema, que incluso la tarea aparentemente simple de encontrar las especificaciones para saber cómo usar las apis de un sistema operativo desde un programa en ensamblador puede ser un infierno.
Otra cosa es que te plantees crear un programa en ensamblador realmente desde cero, es decir, un programa en ensamblador escrito para que funcione en un ordenador en el que ni siquiera haya instalado ningún sistema operativo. En este caso extremo sí que no te tienes que andar peleando con apis ni con protocolos ni especificaciones de sistemas operativos.
Sin embargo, me encantaría avisarte del peligro de generalizar. No es buena idea que afirmes directamente y sin cortapisas que así son todos los profesores. No lo es porque, simplemente, va a ser erróneo que todos sean así.
Por otra parte, eso no habla del tema principal. Aprender ensamblador tiene motivos, valores y usos. Puedes estar más o menos de acuerdo, pero criticar a los profesores no profundiza en el tema
#77 Sí... casi... O sea, por lo que veo, en Java un diccionario es una clase abstracta, y un Map es una interfaz... pero vamos, que el diccionario es una implementación de Map, o sea que...
#80 Ahí tienes razón, lo que me refiero es que hay que tener siempre en cuenta el tiempo de desarollo y usar la tecnología que tenga un balance entre eficiencia, mantenibilidad, facilidad de despliegue, etc. Por ejemplo, en mi vida he visto a mucha gente reinventando la rueda una y otra y otra vez. Si tengo que usar una biblioteca en C++ y para ello necesito un día entero sólo para que compile pues no es práctico. Suele pasar que una librería depende de otra, y esta de otra, etc.
#83 es que precisamente scipy usa C, C++, compilando con Cython seguramente, y Fortran. Si fuera solo Python será totalmente inútil por el bajo rendimiento y la ausencia de tipos específicos.
#6 Lo que noto de tu comentario es que te dedicas o has estando más en contacto con un tipo particular de desarrollo, y no has salido de ese entorno.
Cada lenguaje tiene un proposito determinado y hay motivos bien fundados en no utilizar lenguajes como java o Go cuando el objetivo es programar tareas de bajo nivel. No es una cuestión de abstracciones, que por supuesto las habrá, pero poner una abstracción no significa que : a) siempre puedas usar esa abstracción y b) se deba dejar de programar o mejorar esas capas inferiores.
Es muy, pero que muy dificil que vayas a encontrar lenguajes de alto nivel, incluso C++, en microcontroladores de cualquier tipo, en sensores, en módulos de procesado GPS, en sistemas de tiempo real, en... En general, por cada usuario que mira una web, el entorno que utiliza tiene al menos 10 veces más dispositivos que han sido programados en C o ensamblador que en lenguajes de alto nivel. Por ejemplo, pensamos en el móvil y solo se nos viene a la cabeza el procesador principal con un ARM o similar... pero se nos olvida que ese cacharro tendrá un microcontorlador para la interfaz usb, otro para la interfaz de red, otro para la wifi, otro para controlar el LCD de la pantalla, otro para el GPS, otro para el procesador de audio, y así un largo etcétera.
Si C sigue siendo uno de los lenguajes más utilizados, no es por casualidad, o por el legacy de los sistemas. Es porque da igual donde miremos, allí habrá al menos 40 o 50 dispositivos electornicos que han sido desarrollados en C. No hay mejor alternativa a día de hoy, y de hecho el uso de C ya es alto nivel para muchos de esots casos. El único lenguaje que podría reemplazarle es rust, pero todavía esta en pañales para poder abordar el reemplazo.
Lo que me pregunto es, como es posible que solo pensemos en páginas web y similares cuando pensamos en programación. Es una visión realmente limitada. La única explicación que se me ocurre es que en España, no hay absolutamente nada de industria técnologica. Si lo hubiese, y tuviesemos que fabricar o diseñar baterías, o sensores de cualquier tipo o... bueno, prácticamente lo que sea, entenderíamos hay mucho, pero que mucho trabajo fuera de los java, go, c# y cia.
#6 Para el mercado laboral, con un curso del INEM, le vale. Si estudias la ingeniería, o ahora el grado, es porque quieres aprender todo eso que, en teoría, no sirve en el mercado laboral.
Ahora, si estudias el grado porque quieres trabajar como programador, creo que es una pérdida de tiempo.
#6 me cuelgo de la percha de uno de tus argumentos, y muchas veces, se abusa ya no del JavaScript, sino de Wrappers superiores como Tupeahead. El problema es que, sin conocer básicos de gestión de instrucciones, o memoria, o pila, se puede generar código hipermegaeficiente, sin que el compilador pueda solucionarlo…
Ejemplos:
1/ Uso de fors en lugar de whiles
2/ Tirar de una librería FFT cuando a lo mejor con una pequeña tabla de los valores de 7 senos y cósenos sería suficiente.
Muchos lenguajes de alto nivel dan solo velocidad en el desarrollo, pero un conductor desbocado, sin atenerse a las características del coche y de la vía puede causar una desgracia…
A mi me ha tocado hablar con licenciados en informática que habían escrito un programa y no les funcionaba. No eran capacees de encontrar el porqué. De mis conversaciones con ellos lo que descubrí es que NO SABEN como se implementan las cosas a muy bajo nivel. Pero a veces es necesario. Sí, les resolví el problema, pero no lo comprendieron.
Ejemplos he tenido varios, pero el que más me acojona es cuando uno de estos guarda un importe (dinero en euros) en un float, algo que he tenido que corregir más de una vez. Me venían a mi con el "no me cuadra y lo he hecho todo bien", y menos mal.
#19 Una sola vez escribí un programa (muy corto) en código máquina. Un rollazo que no recomiendo, aunque algo se aprende.
El nivel (lo cerca que estás de los bits) es lo mismo que en ensamblador. El hacer un goto a un incremento de posiciones de memoria en vez de a una etiqueta, la verdad es que no aporta mucho. Solo que aprendes más sobre el procesador.
#25 Lo divertido que me quedó de las tarjetas es el procedimiento para insertar un caracter.
Pones la original en la copiadora, vas azanzando caracter a caracter hasta la columna anterior. Entonces pones la mano apretando con fuerza sobre la original para evitar físicamente que avance y tecleas el nuevo caracter. Para acabar, le das a copiar hasta el final. Voilà.
#78 generalizar tiene un peligro, lo identifico, lo asumo y mantengo mi comentario.
No todos los profesores son así?.
Preguntales a ellos, los que valen duran poco en la universidad pública.
Aprender ensamblador tiene motivos, eso es verdad.
Porqué no construimos nuestra propia alu con tubos de vacío y con su set de instrucciones personalizado o mejor aún usamos tarjetas perforadas? Tenemos que aprender lo básico.
#58 Un programador se sabe muchos trucos para optimizar en assembler. Un compilador se los sabe todos. El compilador de ADA hace código máquina que es a la vez más corto y más rápido que el que produce un programador profesional que sabe mucho assembler.
No tengo datos sobre Rust, pero es el camimo hacia el que ir. El potencial es grande pues es el lenguaje donde se le da al compilador más información sobre lo que pretendes hacer.
#93generalizar tiene un peligro, lo identifico, lo asumo y mantengo mi comentario.
Mantienes tu comentario porque patatas? Sin una sola justificación? Te permites el lujo de generalizar e incluir a todos los profesores universitarios porque tú lo vales? Lo siento, pero creo que si dices esto, ni identificas, ni asumes, ni entiendes la profundidad de la generalización que has hecho. Por no decir lo mucho que menosprecias el trabajo de los profesores y su valía, sin tener datos que apoyen tu afirmación. Cometer el error en una crítica suelta, vale. Tras reflexionar, me parece muy feo.
No todos los profesores son así?.
Preguntales a ellos, los que valen duran poco en la universidad pública.
La afirmación la has hecho tú. No me mandes a mi a demostrar que tú estás equivocado. Eso está más feo aún. Si haces una afirmación, en la que encima denigras personas y las criticas, que menos que te sustentes en algo. Con una actitud como esta, que muestra prepotencia, no se le puede dar mucha validez a lo que dices.
Por otra parte, ¿Es que no puede quedarse alguien en la universidad pública porque quiera? ¿No puede desarrollar su carrera como profesor porque es lo que le apasiona? Otra generalización más para el saco. Vamos, que ya se ve como identificas y asumes las generalizaciones. Aunque, a juzgar por cómo has contestado a la anterior, seguro que también la mantienes, con la misma evidencia de soporte: tu opinión de mala gana y con la única intención de criticar y denigrar. Muy valiosa.
Aprender ensamblador tiene motivos, eso es verdad.
Porqué no construimos nuestra propia alu con tubos de vacío y con su set de instrucciones personalizado o mejor aún usamos tarjetas perforadas? Tenemos que aprender lo básico.
Lo aprendemos. De hecho, para eso están las asignaturas propias de tecnología e historia. Y también hay especializaciones donde se trabaja esto. ¿O acaso piensas que la tecnología sale del aire y ya no hace falta nadie que la cree? ¿Cómo crees que han venido los tubos de vacío a tu cabeza como idea? ¿Por ciencia infusa?
Una vez más, muestras un desprecio y una prepotencia terribles. Diciendo cosas como esta con la única intención de menospreciar la afirmación de tu interlocutor cuando te pone en valor el conocimiento. Todo conocimiento es valioso: el de lo tubos de vacío también. Que tú lo desprecies no muestra nada bueno por tu parte y no convierte al conocimiento en menos valioso. Menos aún cuando tu opinión muestra una carga de negatividad enorme. Puedes ser todo lo prepotente que quieras: eso no te da razón.
Creo que me he equivocado mucho contigo al responderte antes creyendo que eras una persona inteligente que simplemente había cometido un pequeño error de generalización. Ya veo que no es así.
#94 reconozco que desconozco ADA pero dudo mucho de tu afirmación, por muchas razones pero basta señalar que tu mism@ la mencionas que para que un compilador puedar generar asm optimo debe tener muy claro la intención y c y c++ y ahora Rust son los mejores candidatos por eso mismo. Otra de las razones es que si fueran capaces de hacer algo así con ADA deberian ser capaces con otros lenguajes por que el ADA no tien nada que otros muchos lenguajes no tengan en mayor o menor medida, y solo mencionas ADA. He rebuscado informacion y lo que he encontrado dice lo contrario que el C le da palizas. "Un programador se sabe muchos trucos para optimizar en assembler. Un compilador se los sabe todos." Imposible optimizar assembler no es solo como traducir una única instruccion de alto nivel a ensamblador, sino un todo un conjunto. Yo te hablo como programador que competía en compaticiones de programacion de demos graficas en de 4 kilobytes maximo, lo programaba en C le decía la compilador que generara el ensamblador y "optimizaba" el ensamblador donde podía...
Seguramente en unos días subirá el video a YouTube
youtube.com/c/JuanjeJuega
El problema es quién inventará la siguiente generación de microprocesadores (o de cualquier otra tecnología) si ninguno d e los actuales recién graduados está ni remotamente interesado en el proceso, ni se les da los conocimientos para hacerlo.
Perdón por el tocho.
El tema es que a bajo nivel están programados por ejemplo los compiladores, máquinas virtuales o intérpretes. Si nadie estudia seguir desarrollando estos compiladores de bajo nivel, los lenguajes de alto nivel dejan de evolucionar. Y lo que es peor, que para las máquinas (hardware) hace falta conocimientos a un nivel aún más bajo.
No se trata de teoría, también hay práctica. Hay mucho trabajo de esto y es tan necesario como el otro. Otra cosa es que tu vayas a hacer una página web en ensamblador. Eso no lo hace nadie normal, por muy eficiente que pudiera ser.
ADD dirA, dirB y guardarlo en dirC:
LOAD null --> Posición de memoria inicializada con 0
SUB dirA --> Posición de memoria del valor A
STORE temp
LOAD dirB
SUB temp
STORE dirC
*Edit: cosa que pensandolo bien no tendría mucho sentido sin ret.
store.steampowered.com/app/1444480/Turing_Complete/
Un ejemplo sencillo: uno de los ejercicios de una entrevista de trabajo que hice consistía en convertir una función en javascript que era O(n²) a O(n). La solución que esperaban era obvia, y la saqué correctamente. Pero en realidad seguía siendo O(n²) por el sencillo motivo de que lo que "había que hacer" era utilizar un diccionario para así eliminar uno de los bucles internos. El problema es que, por debajo, un diccionario es, o bien O(n), o bien O(sqrt(n)) según use una lista o un árbol, pero en esa función concreta, en cada pasada podía, o leer un dato, o escribirlo, con lo que si era un árbol, lo que ahorrabas al leer te lo gastabas al balancearlo tras escribir, y si era una lista, estabas igual que antes.
Si no sabes cómo van las cosas "bajo el capó", no te enteras de estos detalles y no entiendes por qué, si has reducido tu función de O(n²) a O(N), sigue tardando más o menos lo mismo.
Ese "PARA" es el que, en realidad, arrastra todos los problemas; o, dicho, con otras palabras, el verdadero problema de escribir en ensamblador no es el ensamblador en sí mismo, sino el contexto, es decir, el sistema operativo, en el que escribes ese ensamblador. Porque es con ese contexto con el que realmente te vas a tener que pelear, principalmente buscando la información que necesitas para poder crear un programa compatible con ese sistema operativo. No concibo peor infierno que buscar información para saber cómo crear un programa en ensamblador PARA Windows, especialmente si esa búsqueda de información la intentas realizar entre la información proporcionada por la propia Microsoft.
En definitiva: el problema no es el ensamblador, es el sistema operativo con el que te tienes que pelear para escribir en ensamblador.
Al final, buscar el hash en la lista de hashes del diccionario sigue siendo O(n) si es lineal, u O(sqrt(n)) si usas un árbol (recuerda que tienes primero que localizar el hash, y luego buscar entre todos los elementos con el mismo hash).
Por supuesto, a menos que me esté perdiendo algo, claro... que tampoco es que yo sea un experto en estas cosas
Es más, el compilador va a optimizar mejor que tu pero de pleno.
Ese ensamblador de la 370 que lo primero que te dicen es que si no tienes la secuencia de cabecera, te cargas el timesharing y van a tener que llamar a alguien que lo arregle. Y estas aconojanado cuando corres tus programas de clase simplemente para probar si estas sumando bien 2+2... .
¿La eficiencia, que es la base implícita del existir de toda máquina no es suficiente razón? no es el usarlo directamente, es que usar compiladores que compilen a otro lenguaje, es absurdo, los demás lenguajes son sólo traductores con pérdidas de eficiencia, la IAs generadoras de código harán desaparecer todos los lenguajes que no sean lenguaje máquina, quedando sólo el lenguaje máquina y el lenguaje humano, esto sería lo más lógico.
Yo trabajé varios años en ensamblador, y llegué a hacer un SO en tiempo real muy simple pero efectivo (todavía está en producción hoy día), Port incluido, para la empresa que trabajaba, en ensamblador y C. Te da una idea muy clara de cómo funciona el proveedor y como optimizar procesos.
Un show verles programar, enlazar con colas de mensajes y demás.
en.wikipedia.org/wiki/One-instruction_set_computer
Solo pude llegar a hacer un editor de textos que daba la opción de "encriptar" lo escrito en mi viejo y oxidado Spectrum. Pero lo disfruté como un niño.
Me parece adorable que ahora un profesor se dedique a enseñar eso en sus clases. Me parece básico, por mucho que algunos os empeñeis en no reconocerlo.
espamatica.com/taller-de-ensamblador-para-zx-spectrum-pong/
Es un recurso que es para usarlo puntualmente en determinados puntos críticos, pero no está de más saberlo.
¿Adivina por qué? Precisamente por lo que comento en #7. Los ingenieros que desarrollan compiladores en principio conocen bien las caracteristicas de las especificaciones de las CPUs que sus compiladores sorpotan y cuando pasan el código fuente (convenientemente interpretado y troceado) a la parte del compilador que "compila" se crea el código objeto ensamblándolo teniendo en cuenta todo lo atractivo y relevante que puedan ofrecer las nuevas CPUs. Es decir, el lenguage ensamblador sigue siendo imprescindible, y ya si nos pasamos a microcontroladores tipo Arduino es más que relevante. Estoy de acuerdo en que las nuevas CPUs de Intel y AMD hoy en día puedan contener internamente incluso bloatware :
www.meneame.net/story/intel-on-demand-pago-desbloquear-caracteristicas
También te digo que para crear un buen compilador no se necesitan ni de lejos todas las nuevas características e instrucciones que puedan incorporar las nuevas CPUs, tanto por temas de compatibilidad entre Intel y AMD como por temas de economía y tiempo. Por poner un ejemplo, el set de instrucciones "3DNow" de los AMD K6-2 de finales de los 90 en su momento tuvieron muy poco soporte en compilares populares. Y con el enlace de arriba más de lo mismo, si las CPUs de Intel empiezan a traer características contenidas en los chips de silicio pero hay que pagar a los de Intel por poder activarlas y utilizarlas muchos compiladores directamente no soportarán esas nuevas características, si es que se tratase de características programables y no "cajas negras", claro.
No siempre es más rápido el código que genera un compilador que el que puedes hacer a mano.
De hecho , en la libc y la stl de c++ hay código en ensamblador para ciertas funciones.
C y C++ se consideran por muchos como bajo nivel e incluso he oído decir que es ensamblador de alto nivel, al idealizar la máquina.
Pero el tema es que no siquiera c,y c++ llegan a poder abstraerse o idealizar una CPU al 100% por ejemplo las instrucciones vectoriales de una CPU.
Si tuvieras que hacer uso de una convolución en ensamblador x86 hay una instrucción para hacerla vectorizada, sin embargo los compiladores , no son tan inteligentes como para entender que ese bucle es una convolución,(les falta el contexto).
Por otro lado si te apoyas en una librería y compilada , no sabrá si puede alinear los datos en memoria y usar las instrucciones de copia que se introdujo creo que en peintiun IV ...
Hay un papel bastante viejo, que quería comparar c, ensamblador y Pascal, en cuestión de eficiencia, y salía que el codigo más eficiente era el ensamblador después el de c y después el de Pascal.
Pero eso era en la primera versión de código , les pidieron hacer modificaciones al programa , para validar que pasaría en un desarrollo normal.
El de compilador , no solo costaba cada vez más mantenerlo, sino que se fue volviendo más lento y el de c paso a ocupar la primera posición.
Después introdujeron restricciones de tiempo a la hora de poder hacer las modificaciones, es decir les pedían una modificación y solo podían hacerla en x horas, y ahí Pascal también acabo pasando a c.
De aquí se pueden sacar conclusiones, pero una de ellas es que a largo tiempo , si es mejor trabajar en un lenguaje de alto nivel, aunque sea solo porque podremos gastar más tiempo en optimizarlo , pero que ciertas partes del.codigo que sabes que solo se tocaran una vez,o muy muy pocas,pero que se ejecuten continuamente, compensara hacerlo en ensamblador....
Justo lo que hace libc y la stl.
globalwikionline.com/detial/en/Bootstrapping_(compilers)
- los programadores los hay muy buenos
- compiladores los hay muy tontos
- muchas veces se programa con clases que son muy genericas que tienen todo tipo de codigo superfluo para el uso que realmente necesitas de esa clase y el compilador eso no te lo optimiza...
- alguien tiene que hacer el compilador que es lo que dice #4, de todas maneras #4 no hacen falta tantos programadores a bajo nivel por lo que no es gran problema que no haya tantos..
Las empresas que diseñan microprocesadores son grandes corporaciones con dinero saliéndoles por las orejas. Que paguen cincuenta mil euros anuales más por programador y que los capten y formen recién salidos de la Universidad
Realmente lo que aprendan en la carrera, los módulos o lo que sea es absurdo, lo único importante es aprender a programar mentalmente luego ya aprenderás los idiomas que quieras, te certificará etc etc
Y esto es como cuando te obligaban a leer los tochos infumables con 16 años, creo que es más fácil enseñar a la gente a programar "cosas bonitas" que motiven que a quien le guste el quijote ya se esfuerza el sólito
En la mayoría de entrevistas que tienen mis estudiantes, haber hecho un juego en ensamblador es un activo muy valorado. La mayoría de ellos me comentan que suele ser lo primero por lo que se interesan y les preguntan. En muchos casos, ha resultado ser motivo de que los contraten.
Y respecto a que ensamblador no se usa, resulta que una proporción no despreciable de estudiantes ha terminado haciendo cosas directamente en ensamblador. Tengo varios de ellos en empresas de robótica programando microcontroladores en ensamblador. Algunos están en nvidia de estancia aprendiendo ensamblador de las tarjetas gráficas. Tengo un grupo en ARM que están optimizando rutinas de multiplicación de matrices. Y, como no podía ser de otra manera, tengo a unos cuantos trabajando en compiladores que se ocupan de diseñar lo que el compilador debe producir como salida. De estos últimos, hay bastantes que están siendo contratados ahora mismo para arquitecturas RISC V, en las que hay mucho que hacer todavía con los compiladores.
El mercado laboral es muy diverso, y las necesidades reales también. No creo que estos trabajos sean los más demandados, pero tampoco son residuales. Son un nicho, como otro cualquiera. Eso sí, un nicho donde se cobra bien, porque cada vez hay menos oferta de trabajadores.
Muy a menudo todos caemos en la trampa de pensar que nuestro entorno de conocimiento es representativo del global. Lo cierto es que siempre hay mucho más allá de lo que conocemos :).
Quienes saben ensamblador, suelen opinar que entienden mejor la máquina y los conceptos fundamentales. Gracias a esto, suelen programar mejor en cualquier nivel y asientan mejor los nuevos conocimientos, sobre explicaciones más ajustadas a la realidad. No suelen criticar ensamblador, y ven con buenos ojos su aprendizaje, por los beneficios globales de entendimiento, más que por su uso directo potencial.
Quienes no saben ensamblador no pueden ver todo esto, debido simplemente a que lo desconocen. Suelen pensar en ensamblador como algo difícil, innecesario o incluso arcaico. Suelen asociarlo únicamente a optimización, y refuerzan con ello su carácter innecesario. Es habitual que critiquen la enseñanza/aprendizaje de ensamblador: suelen preferir lenguajes de alto nivel, y argumentar que son más útiles en el día a día o el trabajo. Les suele contrariar o molestar la opinión de quienes saben ensamblador, y suelen rechazarla.
Moraleja extrapolada: ensamblador te hace criticar menos y ser más feliz
Y ahora en serio, dos cosas al respecto:
1. Cambiando ensamblador y sus propiedades por cualquier conocimiento básico X, seguramente pase lo mismo.
2. Hasta la fecha, todos los mejores profesionales programadores que conozco son del tipo 1: saben y valoran ensamblador. La mayoría no lo usa en su día a día (de forma directa), pero valora el conocimiento que tiene gracias a él.
Y el resto creo que te basas en un conocimiento algo anticuado. Hoy en día los compiladores son capaces de reconocer ciertos bucles y convertirlos en instrucciones vectoriales y muchas otras optimizaciones que antes eran impensables. En el 99.9% de los casos el compilador va a generar mejor código ensamblador que un humano para un procesador moderno.
Desde c solo necesitas que exista la función ioctl que es la que se carga de la comunicación con el kernel.
ht tps://subscription.packtpub.com/book/cloud-and-networking/9781801079518/3/ch03lvl1sec69/interfacing-via-the-ioctl-system-call
Que es la que da acceso al kernel.
Por otro lado lo que afirmas es una sobresimplificacion, el compilador no es capaz ni siquiera de transformar los objetos de manera que no se penalice la caché.
Mira la charla de Mike acton
itch.io/jam/cpcretrodev2022
Y un compilador no optimiza objetos si no secuencias de instrucciones. Hay investigación sobre eso, sobretodo en Haskell, pero aún estamos a años de que los compiladores de C/C++ puedan hacer optimizaciones tan complejas.
Los procesadores hoy en día tienen pipelines de ejecución tan complicadas (por ejemplo pueden decidir ejecutar instrucciones en otro orden) que no sale a cuenta intentar escribir prácticamente nada en ensamblador a no ser que estés escribiendo un driver o un dispositivo empotrado.
Esta claro que siquieres salir al mercado rápido necesitas usar frameworks que te dan un montón de cosas hechas, pero trabajo con desarrolladores que no saben nada de sistemas, e ingenieros que tienen que decidir que hardware se compra que creen que saben hacer pruebas de rendimiento y no saben.
Mi más cores en un ordenador tiene que ser mejor ni en alto nivel tiene que ser necesariamente más fácil según que tarea. En un grado en informática hay que salir sabiendo lo suficiente de bajo nivel, aunque luego no se vayan a utilizar. Y de todas maneras saber que pasa por debajo ayuda a hacer las cosas mejor.
Te enseñan a programar en lo que sabe programar tu profesor, que lleva sin mirar por la ventana a ver qué pasa en el mundo exterior desde hace 30 años.
Con la escusa de "aprendiendo lo básico es importante".
Lo mismo pasa con compartir ordenador y puestos de laboratorio para "incentivar el trabajo en equipo"
Mediocridad aristoacadémica de bigote y naftalina y recortes
Y tú, mierdatizero, déjanos en paz, gracias.
Otra cosa es que te plantees crear un programa en ensamblador realmente desde cero, es decir, un programa en ensamblador escrito para que funcione en un ordenador en el que ni siquiera haya instalado ningún sistema operativo. En este caso extremo sí que no te tienes que andar peleando con apis ni con protocolos ni especificaciones de sistemas operativos.
Sin embargo, me encantaría avisarte del peligro de generalizar. No es buena idea que afirmes directamente y sin cortapisas que así son todos los profesores. No lo es porque, simplemente, va a ser erróneo que todos sean así.
Por otra parte, eso no habla del tema principal. Aprender ensamblador tiene motivos, valores y usos. Puedes estar más o menos de acuerdo, pero criticar a los profesores no profundiza en el tema
Va más alla del hardware o trabajar en intel.
Cada lenguaje tiene un proposito determinado y hay motivos bien fundados en no utilizar lenguajes como java o Go cuando el objetivo es programar tareas de bajo nivel. No es una cuestión de abstracciones, que por supuesto las habrá, pero poner una abstracción no significa que : a) siempre puedas usar esa abstracción y b) se deba dejar de programar o mejorar esas capas inferiores.
Es muy, pero que muy dificil que vayas a encontrar lenguajes de alto nivel, incluso C++, en microcontroladores de cualquier tipo, en sensores, en módulos de procesado GPS, en sistemas de tiempo real, en... En general, por cada usuario que mira una web, el entorno que utiliza tiene al menos 10 veces más dispositivos que han sido programados en C o ensamblador que en lenguajes de alto nivel. Por ejemplo, pensamos en el móvil y solo se nos viene a la cabeza el procesador principal con un ARM o similar... pero se nos olvida que ese cacharro tendrá un microcontorlador para la interfaz usb, otro para la interfaz de red, otro para la wifi, otro para controlar el LCD de la pantalla, otro para el GPS, otro para el procesador de audio, y así un largo etcétera.
Si C sigue siendo uno de los lenguajes más utilizados, no es por casualidad, o por el legacy de los sistemas. Es porque da igual donde miremos, allí habrá al menos 40 o 50 dispositivos electornicos que han sido desarrollados en C. No hay mejor alternativa a día de hoy, y de hecho el uso de C ya es alto nivel para muchos de esots casos. El único lenguaje que podría reemplazarle es rust, pero todavía esta en pañales para poder abordar el reemplazo.
Lo que me pregunto es, como es posible que solo pensemos en páginas web y similares cuando pensamos en programación. Es una visión realmente limitada. La única explicación que se me ocurre es que en España, no hay absolutamente nada de industria técnologica. Si lo hubiese, y tuviesemos que fabricar o diseñar baterías, o sensores de cualquier tipo o... bueno, prácticamente lo que sea, entenderíamos hay mucho, pero que mucho trabajo fuera de los java, go, c# y cia.
Ahora, si estudias el grado porque quieres trabajar como programador, creo que es una pérdida de tiempo.
Ejemplos:
1/ Uso de fors en lugar de whiles
2/ Tirar de una librería FFT cuando a lo mejor con una pequeña tabla de los valores de 7 senos y cósenos sería suficiente.
Muchos lenguajes de alto nivel dan solo velocidad en el desarrollo, pero un conductor desbocado, sin atenerse a las características del coche y de la vía puede causar una desgracia…
Ejemplos he tenido varios, pero el que más me acojona es cuando uno de estos guarda un importe (dinero en euros) en un float, algo que he tenido que corregir más de una vez. Me venían a mi con el "no me cuadra y lo he hecho todo bien", y menos mal.
El nivel (lo cerca que estás de los bits) es lo mismo que en ensamblador. El hacer un goto a un incremento de posiciones de memoria en vez de a una etiqueta, la verdad es que no aporta mucho. Solo que aprendes más sobre el procesador.
Pones la original en la copiadora, vas azanzando caracter a caracter hasta la columna anterior. Entonces pones la mano apretando con fuerza sobre la original para evitar físicamente que avance y tecleas el nuevo caracter. Para acabar, le das a copiar hasta el final. Voilà.
Qué maravilla que son los editores.
No todos los profesores son así?.
Preguntales a ellos, los que valen duran poco en la universidad pública.
Aprender ensamblador tiene motivos, eso es verdad.
Porqué no construimos nuestra propia alu con tubos de vacío y con su set de instrucciones personalizado o mejor aún usamos tarjetas perforadas? Tenemos que aprender lo básico.
No tengo datos sobre Rust, pero es el camimo hacia el que ir. El potencial es grande pues es el lenguaje donde se le da al compilador más información sobre lo que pretendes hacer.
Mantienes tu comentario porque patatas? Sin una sola justificación? Te permites el lujo de generalizar e incluir a todos los profesores universitarios porque tú lo vales? Lo siento, pero creo que si dices esto, ni identificas, ni asumes, ni entiendes la profundidad de la generalización que has hecho. Por no decir lo mucho que menosprecias el trabajo de los profesores y su valía, sin tener datos que apoyen tu afirmación. Cometer el error en una crítica suelta, vale. Tras reflexionar, me parece muy feo.
No todos los profesores son así?.
Preguntales a ellos, los que valen duran poco en la universidad pública.
La afirmación la has hecho tú. No me mandes a mi a demostrar que tú estás equivocado. Eso está más feo aún. Si haces una afirmación, en la que encima denigras personas y las criticas, que menos que te sustentes en algo. Con una actitud como esta, que muestra prepotencia, no se le puede dar mucha validez a lo que dices.
Por otra parte, ¿Es que no puede quedarse alguien en la universidad pública porque quiera? ¿No puede desarrollar su carrera como profesor porque es lo que le apasiona? Otra generalización más para el saco. Vamos, que ya se ve como identificas y asumes las generalizaciones. Aunque, a juzgar por cómo has contestado a la anterior, seguro que también la mantienes, con la misma evidencia de soporte: tu opinión de mala gana y con la única intención de criticar y denigrar. Muy valiosa.
Aprender ensamblador tiene motivos, eso es verdad.
Porqué no construimos nuestra propia alu con tubos de vacío y con su set de instrucciones personalizado o mejor aún usamos tarjetas perforadas? Tenemos que aprender lo básico.
Lo aprendemos. De hecho, para eso están las asignaturas propias de tecnología e historia. Y también hay especializaciones donde se trabaja esto. ¿O acaso piensas que la tecnología sale del aire y ya no hace falta nadie que la cree? ¿Cómo crees que han venido los tubos de vacío a tu cabeza como idea? ¿Por ciencia infusa?
Una vez más, muestras un desprecio y una prepotencia terribles. Diciendo cosas como esta con la única intención de menospreciar la afirmación de tu interlocutor cuando te pone en valor el conocimiento. Todo conocimiento es valioso: el de lo tubos de vacío también. Que tú lo desprecies no muestra nada bueno por tu parte y no convierte al conocimiento en menos valioso. Menos aún cuando tu opinión muestra una carga de negatividad enorme. Puedes ser todo lo prepotente que quieras: eso no te da razón.
Creo que me he equivocado mucho contigo al responderte antes creyendo que eras una persona inteligente que simplemente había cometido un pequeño error de generalización. Ya veo que no es así.
¿es un test? ¿es una demo? ¿es para cobrar una subvención?
"Un programador se sabe muchos trucos para optimizar en assembler. Un compilador se los sabe todos." Imposible optimizar assembler no es solo como traducir una única instruccion de alto nivel a ensamblador, sino un todo un conjunto. Yo te hablo como programador que competía en compaticiones de programacion de demos graficas en de 4 kilobytes maximo, lo programaba en C le decía la compilador que generara el ensamblador y "optimizaba" el ensamblador donde podía...