Portada
mis comunidades
otras secciones
#8:
Yo hice la carrera de Informática en los años 90 y a lo largo de varios cursos nos explicaron cómo está hecho un procesador, empezando por lo más básico. Desde los transistores a las puertas lógicas, operadores aritméticos... de ahí a componentes básicos de memoria, instrucciones de control, etc... Al cabo de tres cursos, teníamos una idea cabal de cómo estaba hecho un Intel 80386. No sé si hoy en día se sigue enseñando esto. Muchos compañeros lo consideraban inútil y era una asignatura hueso, pero a mí me pareció interesante y necesario aunque no le haya dado un uso práctico en el trabajo.
#14:
#8 Las materias "inútiles" no necesariamente son tan inútiles. Un ejemplo es Steve Jobs, que recibió clases de caligrafía y gracias a ellas se le ocurrió que el procesador de palabras de la primera Mac tuviera tipos de letras diferentes.
Todo lo que aprendemos sirve para algo (cuando nos tropecemos con ese algo en que se puede usar o que puede ser entendido mejor por el conocimiento que tenemos).
La programación en assembler, por ejemplo, dudo mucho que sea inútil (el problema es que se lleva demasiado tiempo ser un experto). Alguien que sea experto o más que experto en ella entiende muy bien la arquitectura del computador y en qué se convierten los programas compilados. Mientras que en alto nivel existen tipos de datos, enteros, caracteres, punto flotante, binarios, por ejemplo, a nivel de assembler eso no existe, eso es solo un constructo, una ilusión, a nivel de assembler todo, absolutamente todo son simples bytes (con sus múltiplos y submúltiplos), y es exactamente lo mismo un caracter que un entero, todo depende de cómo se interprete. Es como el nivel atómico, no hay diferencia entre lo orgánico y lo inorgánico, todo es lo mismo.
Adicionalmente, un experto en assembler (y que programe allí con toda fluidez) tendrá habilidades "sobrehumanas" a nivel de lenguajes de alto nivel, que será tan sencillo que prácticamente no tendrá ni que pensar o pensar muy poco para un gran número de cosas (tendrá que aprender de un enorme número de APIs para dominar realmente un lenguaje de alto nivel, junto con los conceptos de ciencias de la programación como estructuras de datos, etc), pero en cuanto habilidad para programar se vuelve algo trivial.
Todo lo que aprendemos sirve para algo (cuando nos tropecemos con ese algo en que se puede usar o que puede ser entendido mejor por el conocimiento que tenemos).
La programación en assembler, por ejemplo, dudo mucho que sea inútil (el problema es que se lleva demasiado tiempo ser un experto). Alguien que sea experto o más que experto en ella entiende muy bien la arquitectura del computador y en qué se convierten los programas compilados. Mientras que en alto nivel existen tipos de datos, enteros, caracteres, punto flotante, binarios, por ejemplo, a nivel de assembler eso no existe, eso es solo un constructo, una ilusión, a nivel de assembler todo, absolutamente todo son simples bytes (con sus múltiplos y submúltiplos), y es exactamente lo mismo un caracter que un entero, todo depende de cómo se interprete. Es como el nivel atómico, no hay diferencia entre lo orgánico y lo inorgánico, todo es lo mismo.
Adicionalmente, un experto en assembler (y que programe allí con toda fluidez) tendrá habilidades "sobrehumanas" a nivel de lenguajes de alto nivel, que será tan sencillo que prácticamente no tendrá ni que pensar o pensar muy poco para un gran número de cosas (tendrá que aprender de un enorme número de APIs para dominar realmente un lenguaje de alto nivel, junto con los conceptos de ciencias de la programación como estructuras de datos, etc), pero en cuanto habilidad para programar se vuelve algo trivial.
#18:
#16 Tengo un amigo que lo hace, lo de entender ensamblador de algunas familias de microprocesadores y microcontroladores, hasta el punto de que se ha hecho su propio sistema operativo y algunas aplicaciones para x86 que usa para varias tareas personales de su día a día.
Los demás pensamos que es especial, pero le queremos igual.
Los demás pensamos que es especial, pero le queremos igual.
#19:
#16 No es difícil. Depende del lenguaje compilado. Los lenguajes de antes (procedurimentales) eran muy sencillos. Yo estuve meses ejecutando manualmente paso por paso (con un debuger) muchos programas y entendiendo cómo funcionaban a nivel de assembler. Dentro de ellos el interpretador BASIC de IBM (hecho por Microsoft), el programa de ajedrez SARGON III, y el sistema operativo MS DOS, programas compilados con el compilador BASCOM de Microsoft, que compilaba programas en BASIC, etc.
En el caso de programas compilados es mucho más fácil que programas hechos en assembler. Los compiladores de hoy (y ayer) son sumamente rudimentarios y solo usan un muy pequeño conjunto de instrucciones del CPU, siempre las mismas, y hay un patrón que se repite casi igual, (con muy pequeñas variaciones), al traducir las instrucciones de alto nivel. No tienen la habilidad de hacer buenos programas en assembler, de hecho son desastrosos, generan programas sumamente malos e ineficientes, aunque mucho mejores que los de un novato en assembler (por eso los libros de texto, escritos por gente que no sabe nada de lo que habla, dicen que los compiladores compilan programas casi tan buenos que los de un desarrollador humano) MENTIRA.
Un buen programador en assembler podría hacer programas mucho más compactos y más rápidos que cualquier compilador actual, tanto como 3, 5 10, 20 veces más rápido y a veces muchísimo más (decenas y cientos de veces más). No solo por el dominio del assembler en sí mismo, sino por el conocimiento de cómo son las cosas realmente y la habilidad que tiene al crear algoritmos sumamente eficientes. Un ejemplo:
Si se copia un terabyte de archivos grandes es muy rápido, pero si en vez de archivos grandes son archivos miniatura (digamos de 1 KB cada uno), la cosa es diferente, puede muchas decenas de veces más. ¿por qué? Por la terriblemente mala manera de hacerlo. Los archivos están almacenados en clusters (grupos de varios sectores que se manejan a la vez). Cada vez que se va a copiar un archivo, se lee la entrada del archivo y luego las entradas de la tabla FAT (o equivalente) donde se indica dónde están cada uno de los clusters del archivo y se copian esos clusters creando el nuevo archivo (junto con las entradas en la tabla que indican dónde están los cluster.
Con archivos pequeños es un desastre. Constantemente se está yendo a 1. la especificación del archivo, luego a 2. leer las entradas a la tabla que indica donde están los clusters (como es pequeño solo hay un cluster), y luego 3. se copia el cluster. La cabeza lectora se mueve a esas tres áreas constantemente (en la lectura y luego otras tantas veces en la escritura). Con los archivos grandes no hay problema porque el tiempo hacia la especificación del archivo y la tabla de posición de los clusters (1 y 2) es mínimo comparado con la copia del archivo en sí (3), pero con los pequeños se tarda más tiempo en leer la especificación del archivo y la tabla de posición de los cluster (1 y 2) que la propia copia (3). Por eso se tarda una eternidad con archivos pequeños. Millones de saltos de la cabeza lectora una y otra vez, al menos 3 por cada archivo.
¿La solución? Muy sencilla. No pongas la cabeza lectora a pegar todos esos saltos cada vez que va a copiar un archivo. Lee primero un montón de especificaciones de archivos, luego lees secuencialmente (de acuerdo a su posición) la tabla de posición de los clusters de todos esos archivos, Lee los cluster también secuencialmente (de acuerdo a su posición) de todos esos archivos, y los escribes secuencialmente. Así la cabeza lectora no pega tantos brincos para atrás y para adelante. ¿Resultado? la copia de archivos pequeños sería muchas decenas de veces más rápida como mínimo, en ciertos casos más de cien veces más rápida.
Nada de eso se puede ver pensando ni viendo las cosas en alto nivel, solo mirando las cosas a nivel atómico, visión que tiene solo el que maneja las cosas a muy bajo nivel (como el desarrolador en assembler o el que hace determinadas rutinas en el sistema operativo). Lo que lo hace tan rápido no es el conocimiento del assembler en sí, sino habilidades añadias que surgen al conocer el assembler y un conocimiento muy profundo de las cosas.
Es cierto que el assembler no se va a usar en todo. Solo en cosas muy específicas que no llegarían ni al 1% de los programas, pero usado correctamente (inclusive hoy en día), nos haría entrar en una nueva era, resolviendo incluso problemas energéticos, bajando el consumo de energía muy significativamente. Además de hacer los computadores muchísimo más rápidos de lo que la gente se imagina. Lástima que es un arte perdido.
En el caso de programas compilados es mucho más fácil que programas hechos en assembler. Los compiladores de hoy (y ayer) son sumamente rudimentarios y solo usan un muy pequeño conjunto de instrucciones del CPU, siempre las mismas, y hay un patrón que se repite casi igual, (con muy pequeñas variaciones), al traducir las instrucciones de alto nivel. No tienen la habilidad de hacer buenos programas en assembler, de hecho son desastrosos, generan programas sumamente malos e ineficientes, aunque mucho mejores que los de un novato en assembler (por eso los libros de texto, escritos por gente que no sabe nada de lo que habla, dicen que los compiladores compilan programas casi tan buenos que los de un desarrollador humano) MENTIRA.
Un buen programador en assembler podría hacer programas mucho más compactos y más rápidos que cualquier compilador actual, tanto como 3, 5 10, 20 veces más rápido y a veces muchísimo más (decenas y cientos de veces más). No solo por el dominio del assembler en sí mismo, sino por el conocimiento de cómo son las cosas realmente y la habilidad que tiene al crear algoritmos sumamente eficientes. Un ejemplo:
Si se copia un terabyte de archivos grandes es muy rápido, pero si en vez de archivos grandes son archivos miniatura (digamos de 1 KB cada uno), la cosa es diferente, puede muchas decenas de veces más. ¿por qué? Por la terriblemente mala manera de hacerlo. Los archivos están almacenados en clusters (grupos de varios sectores que se manejan a la vez). Cada vez que se va a copiar un archivo, se lee la entrada del archivo y luego las entradas de la tabla FAT (o equivalente) donde se indica dónde están cada uno de los clusters del archivo y se copian esos clusters creando el nuevo archivo (junto con las entradas en la tabla que indican dónde están los cluster.
Con archivos pequeños es un desastre. Constantemente se está yendo a 1. la especificación del archivo, luego a 2. leer las entradas a la tabla que indica donde están los clusters (como es pequeño solo hay un cluster), y luego 3. se copia el cluster. La cabeza lectora se mueve a esas tres áreas constantemente (en la lectura y luego otras tantas veces en la escritura). Con los archivos grandes no hay problema porque el tiempo hacia la especificación del archivo y la tabla de posición de los clusters (1 y 2) es mínimo comparado con la copia del archivo en sí (3), pero con los pequeños se tarda más tiempo en leer la especificación del archivo y la tabla de posición de los cluster (1 y 2) que la propia copia (3). Por eso se tarda una eternidad con archivos pequeños. Millones de saltos de la cabeza lectora una y otra vez, al menos 3 por cada archivo.
¿La solución? Muy sencilla. No pongas la cabeza lectora a pegar todos esos saltos cada vez que va a copiar un archivo. Lee primero un montón de especificaciones de archivos, luego lees secuencialmente (de acuerdo a su posición) la tabla de posición de los clusters de todos esos archivos, Lee los cluster también secuencialmente (de acuerdo a su posición) de todos esos archivos, y los escribes secuencialmente. Así la cabeza lectora no pega tantos brincos para atrás y para adelante. ¿Resultado? la copia de archivos pequeños sería muchas decenas de veces más rápida como mínimo, en ciertos casos más de cien veces más rápida.
Nada de eso se puede ver pensando ni viendo las cosas en alto nivel, solo mirando las cosas a nivel atómico, visión que tiene solo el que maneja las cosas a muy bajo nivel (como el desarrolador en assembler o el que hace determinadas rutinas en el sistema operativo). Lo que lo hace tan rápido no es el conocimiento del assembler en sí, sino habilidades añadias que surgen al conocer el assembler y un conocimiento muy profundo de las cosas.
Es cierto que el assembler no se va a usar en todo. Solo en cosas muy específicas que no llegarían ni al 1% de los programas, pero usado correctamente (inclusive hoy en día), nos haría entrar en una nueva era, resolviendo incluso problemas energéticos, bajando el consumo de energía muy significativamente. Además de hacer los computadores muchísimo más rápidos de lo que la gente se imagina. Lástima que es un arte perdido.
Comentarios
Yo hice la carrera de Informática en los años 90 y a lo largo de varios cursos nos explicaron cómo está hecho un procesador, empezando por lo más básico. Desde los transistores a las puertas lógicas, operadores aritméticos... de ahí a componentes básicos de memoria, instrucciones de control, etc... Al cabo de tres cursos, teníamos una idea cabal de cómo estaba hecho un Intel 80386. No sé si hoy en día se sigue enseñando esto. Muchos compañeros lo consideraban inútil y era una asignatura hueso, pero a mí me pareció interesante y necesario aunque no le haya dado un uso práctico en el trabajo.
#8 Yo diría que aún se enseña, al menos parte. En primero se sigue enseñando fundamentos de computadores (al menos cuando he mirado planes de informática que alguna vez he pensado en estudiarla).
#8 yo empecé la carrera en el 2001 y no solo nos explicaban los componentes de la CPU desde el transistor, también nos enseñaban la física que hay detrás de un transistor. También teníamos prácticas. Lo que hicimos distaba mucho de ser una CPU pero podías ver los fundamentos básicos en los que se basan. Las hacíamos con un simulador.
#10 Mi práctica favorita de toda la carrera fue montar un procesador 8085 en una placa, con su EPROM y su RAM, con todas las conexiones hechas mediante cables wrapinados a mano. La alimentación era una pila de 9V. Las entradas y salidas eran varios interruptores y luces o displays, según de lo que tratara tu proyecto. Se desarrollaba un programa que llevabas en un diskete y te lo grababan en la EPROM del aparato. Si todo iba bien, tenías un "ordenador" que cabía en la palma de la mano, el tatarabuelo de la Raspberry Pi.
#8 Las materias "inútiles" no necesariamente son tan inútiles. Un ejemplo es Steve Jobs, que recibió clases de caligrafía y gracias a ellas se le ocurrió que el procesador de palabras de la primera Mac tuviera tipos de letras diferentes.
Todo lo que aprendemos sirve para algo (cuando nos tropecemos con ese algo en que se puede usar o que puede ser entendido mejor por el conocimiento que tenemos).
La programación en assembler, por ejemplo, dudo mucho que sea inútil (el problema es que se lleva demasiado tiempo ser un experto). Alguien que sea experto o más que experto en ella entiende muy bien la arquitectura del computador y en qué se convierten los programas compilados. Mientras que en alto nivel existen tipos de datos, enteros, caracteres, punto flotante, binarios, por ejemplo, a nivel de assembler eso no existe, eso es solo un constructo, una ilusión, a nivel de assembler todo, absolutamente todo son simples bytes (con sus múltiplos y submúltiplos), y es exactamente lo mismo un caracter que un entero, todo depende de cómo se interprete. Es como el nivel atómico, no hay diferencia entre lo orgánico y lo inorgánico, todo es lo mismo.
Adicionalmente, un experto en assembler (y que programe allí con toda fluidez) tendrá habilidades "sobrehumanas" a nivel de lenguajes de alto nivel, que será tan sencillo que prácticamente no tendrá ni que pensar o pensar muy poco para un gran número de cosas (tendrá que aprender de un enorme número de APIs para dominar realmente un lenguaje de alto nivel, junto con los conceptos de ciencias de la programación como estructuras de datos, etc), pero en cuanto habilidad para programar se vuelve algo trivial.
#14 Yo conocí a un tipo que podía "leer" código en assembler, como quien lee una novela. Iba mirando un programa compilado y nos iba explicando en voz alta sobre la marcha lo que hacía. Pero no traduciendo las instrucciones, sino realmente entendiendo a alto nivel el objetivo de ese código.
#16 Tengo un amigo que lo hace, lo de entender ensamblador de algunas familias de microprocesadores y microcontroladores, hasta el punto de que se ha hecho su propio sistema operativo y algunas aplicaciones para x86 que usa para varias tareas personales de su día a día.
Los demás pensamos que es especial, pero le queremos igual.
#16 No es difícil. Depende del lenguaje compilado. Los lenguajes de antes (procedurimentales) eran muy sencillos. Yo estuve meses ejecutando manualmente paso por paso (con un debuger) muchos programas y entendiendo cómo funcionaban a nivel de assembler. Dentro de ellos el interpretador BASIC de IBM (hecho por Microsoft), el programa de ajedrez SARGON III, y el sistema operativo MS DOS, programas compilados con el compilador BASCOM de Microsoft, que compilaba programas en BASIC, etc.
En el caso de programas compilados es mucho más fácil que programas hechos en assembler. Los compiladores de hoy (y ayer) son sumamente rudimentarios y solo usan un muy pequeño conjunto de instrucciones del CPU, siempre las mismas, y hay un patrón que se repite casi igual, (con muy pequeñas variaciones), al traducir las instrucciones de alto nivel. No tienen la habilidad de hacer buenos programas en assembler, de hecho son desastrosos, generan programas sumamente malos e ineficientes, aunque mucho mejores que los de un novato en assembler (por eso los libros de texto, escritos por gente que no sabe nada de lo que habla, dicen que los compiladores compilan programas casi tan buenos que los de un desarrollador humano) MENTIRA.
Un buen programador en assembler podría hacer programas mucho más compactos y más rápidos que cualquier compilador actual, tanto como 3, 5 10, 20 veces más rápido y a veces muchísimo más (decenas y cientos de veces más). No solo por el dominio del assembler en sí mismo, sino por el conocimiento de cómo son las cosas realmente y la habilidad que tiene al crear algoritmos sumamente eficientes. Un ejemplo:
Si se copia un terabyte de archivos grandes es muy rápido, pero si en vez de archivos grandes son archivos miniatura (digamos de 1 KB cada uno), la cosa es diferente, puede muchas decenas de veces más. ¿por qué? Por la terriblemente mala manera de hacerlo. Los archivos están almacenados en clusters (grupos de varios sectores que se manejan a la vez). Cada vez que se va a copiar un archivo, se lee la entrada del archivo y luego las entradas de la tabla FAT (o equivalente) donde se indica dónde están cada uno de los clusters del archivo y se copian esos clusters creando el nuevo archivo (junto con las entradas en la tabla que indican dónde están los cluster.
Con archivos pequeños es un desastre. Constantemente se está yendo a 1. la especificación del archivo, luego a 2. leer las entradas a la tabla que indica donde están los clusters (como es pequeño solo hay un cluster), y luego 3. se copia el cluster. La cabeza lectora se mueve a esas tres áreas constantemente (en la lectura y luego otras tantas veces en la escritura). Con los archivos grandes no hay problema porque el tiempo hacia la especificación del archivo y la tabla de posición de los clusters (1 y 2) es mínimo comparado con la copia del archivo en sí (3), pero con los pequeños se tarda más tiempo en leer la especificación del archivo y la tabla de posición de los cluster (1 y 2) que la propia copia (3). Por eso se tarda una eternidad con archivos pequeños. Millones de saltos de la cabeza lectora una y otra vez, al menos 3 por cada archivo.
¿La solución? Muy sencilla. No pongas la cabeza lectora a pegar todos esos saltos cada vez que va a copiar un archivo. Lee primero un montón de especificaciones de archivos, luego lees secuencialmente (de acuerdo a su posición) la tabla de posición de los clusters de todos esos archivos, Lee los cluster también secuencialmente (de acuerdo a su posición) de todos esos archivos, y los escribes secuencialmente. Así la cabeza lectora no pega tantos brincos para atrás y para adelante. ¿Resultado? la copia de archivos pequeños sería muchas decenas de veces más rápida como mínimo, en ciertos casos más de cien veces más rápida.
Nada de eso se puede ver pensando ni viendo las cosas en alto nivel, solo mirando las cosas a nivel atómico, visión que tiene solo el que maneja las cosas a muy bajo nivel (como el desarrolador en assembler o el que hace determinadas rutinas en el sistema operativo). Lo que lo hace tan rápido no es el conocimiento del assembler en sí, sino habilidades añadias que surgen al conocer el assembler y un conocimiento muy profundo de las cosas.
Es cierto que el assembler no se va a usar en todo. Solo en cosas muy específicas que no llegarían ni al 1% de los programas, pero usado correctamente (inclusive hoy en día), nos haría entrar en una nueva era, resolviendo incluso problemas energéticos, bajando el consumo de energía muy significativamente. Además de hacer los computadores muchísimo más rápidos de lo que la gente se imagina. Lástima que es un arte perdido.
#19 Sale muchísimo más barato el kilo de carne de programador de Java o m$.net que el kilo de carne de programador de ensamblador.
¿Con o sin vulnerabilidades de Intel?
#1: Primero tienes que entender lo que es un "latch".
#2 ¿Eso no es leche en Aleman suizo?
#3 No, es vergüenza en caló alemán.
#2 por cierto, estoy atascado en la fase del Latch y siguiendo la wikipedia no me lo acepta.
#22: El latch al menos tiene una ayuda, lo que hay que hacer es conectar la salida a una de las entradas.
#23 gracias, genial. Me estaba complicando y basta un solo componente para resolverlo
#22 El latch la verdad es que nunca lo toqué así en la carrera, lo que usábamos era un flip-flop RS de toda la vida. Y no sé hasta que punto se llega a usar este tipo de biestable en la práctica.
Aquí tienes una foto de como lo he montado.
#29 si, es la misma solucion a la que llegue yo
https://www.nand2tetris.org/
Este libro que se basa en hacer ejercicios en un emulador también está muy bien para aprender los principios básicos teóricos desde la cpu hasta un intérprete basado en máquina virtual.
Tienen también cursos en Coursera
Me ha recordado al libro "But How Do It Know? - The Basic Principles of Computers for Everyone" donde paso a paso te va instruyendo para crear un ordenador, usando únicamente puertas lógicas NAND.
Bastante recomendable .
https://www.amazon.com/But-How-Know-Principles-Computers/dp/0615303765
Comienza con el ensamblaje de puertas lógicas basado en puertas lógicas más sencillas, luego componentes para hacer aritmética binaria, como Half Adder y Full Adder, y después componentes más complejos hasta llegar a un CPU.
Todavía incompleto y muy difícil si no se tiene cierta documentación, pero Internet está llena de ésta.
#4 Así es como nos enseñaron a nosotros en fp la electrónica digital y la verdad que se me quedo bastante bien... empezamos con componentes discretos a crear puertas lógicas y usándolas crear otros tipos de circuitos cada vez mas complejos usando elementos anteriores hasta llegar a los distintos arrays de datos.
#4 "Never Go Full Adder"
Estoy en el "Instruction decoder" y debería funcionar pero me da error en un output al menos. ¿Alguien se lo ha pasado?
yo en la carrera diseñé un procesador de 12 estados... la verdad que lo recuerdo como todo un reto... subir de los 10 estados era jodido
Por los ejemplos parece un simulador de circuitos lógicos, más que una herramienta para entender como funciona un procesador. Ese conocimiento está en un nivel de abstracción más alto. Por ejemplo, para entender un procesador no hace falta conocer el detalle de la lógica de las unidades de suma/resta de enteros.
#11 Va subiendo de nivel. Comienza con la creación de circuitos básicos, luego funciones aritméticas, después circuitos cada vez más complejos hasta llegar al CPU (ver sección de la derecha http://nandgame.com/)
Lo malo es que no es un simulador donde se vean los circuitos trabajando. Hay algunos libres.
#12 si hay simulador: http://www.buthowdoitknow.com/cpu_model_intro.html incluso en excell
Paso a paso https://www.cs.drexel.edu/~bls96/museum/cardiac.html
Otro que mola mucho es Cardiac, simula el funcionamiento de una CPU con papel, con su memoria, instrucciones, registro....
https://www.cs.drexel.edu/~bls96/museum/cardiac.html
Por ahí andan los PDFs para imprimirlo y el manual de uso.
Me he quedado en la puerta or
me encantaaaaaaaaa!!!