duda sobre hardware y programacion

saludo foro...

tengo una curiosidad no se donde ponerlo por q trata sobre hardware y programasion asi que lo coloco a qui y si no es a quie me disculpo.

es que quiero saver o mas bien es por curiosidad, como es que un programa compliado habla con el hardware es desir a 0 y 1 como es
que de esto ejemplo #include <stedio.h> main ( printf "hola mundo";) pasa a esto 1110 1101 y nose si saben de un libro que me puede desir
que hable de ese proceso.

gracias

Ahora no se de ningún libro, sin embargo te puedo explicar, más o menos, el proceso. Espero que alguien me corrija si me equivoco.

En el mundo de la informática, existe un tipo de software que se encarga de traducir el código fuente de un programa (lo que tu has escrito) a código ensamblador (lenguaje de programación de más bajo nivel). Este tipo de software son los llamados compiladores.

Para cada lenguaje de programación necesitamos un compilador diferente, o almenos, un compilador que reconozca dicho lenguaje de programación. Por otro lado, tenemos los procesadores. Cada procesador puede reconocer un tipo ensamblador u otro. En general, se habla de ensamblador en general, sin embargo, dependiendo del procesador el lenguaje ensamblador tendrá varias diferencias. No es lo mismo el lenguaje ensamblador de un procesador intel, que de un fujitsu. Cada compilador, a parte de reconocer el lenguaje de programación de alto nivel (lo que tu has escrito) debe ser capaz de traducir dicho lenguaje a el lenguaje ensamblador correspondiente al procesador.

Una vez hecho esto, el procesador será capaz de reconocer dicho lenguaje ensamblador. Así pues, cuando el procesador reconozca una instrucción, esta será traducida a sus correspondientes 1 y 0. El procesador puede realizar esta traducción ya que el lenguaje ensamblador es bastante más limitado (o sinácticamente/semánticamente menos complejo) que un lenguaje de alto nivel.

Espero que te haya quedado claro. Y si alguien detecta algún error, que lo comente.

P.D.: Se que eres nuevo por aquí. Bienvenido! Espero que estés a gusto! Por otro lado, intenta fijarte un poco más cuando escribas e intenta hacer menos faltas. Así nos entenderemos mejor todos. Aquí, somos un poco más quisquillosos que en otros sitios con este tema. Pero no te preocupes

saludos

gracias NewLog y siento todos las fallas... para la proximas are menos.

me siento agusto en el foro, gracias por dejarme pertenecer.

gracias...

Hola,

Yo no diría que el compilador traduce el código a ensamblador... yo usaría 'código máquina' más bien. Aunque es cierto que el ensamblador y el código máquina tiene una relación muy directa (1 a 1 realmente, salvo labels y esas cosas si no hay símbolos de debugging).

El procesador no interpreta ensamblador sino su juego de instrucciones. El ensamblador es básicamente una representación más amigable del juego de instrucciones para que seamos capaces de acordarnos de él y entenderlo

En cuanto al funcionamiento del procesador, básicamente se encarga de obtener la siguiente instrucción de memoria (para saber cual es mantiene una referencia a la siguiente instrucción a ejecutar), la decodifica, obtiene operandos (registros, inmediatos, etc) y ejecuta. Finalmente realiza el 'write-back' del resultado sea a memoria o a un registro.

Un procesador actual realiza estas tareas en una serie de etapas, de forma que por ejemplo mientras la parte de ejecución está ocupada con una instrucción, la parte de decodificación está ocupada decodificando la siguiente para aprovechar mejor el tiempo.

Estos conceptos los puedes encontrar en cualquier libro/curso de fundamentos y arquitectura de computadores. No sé darte referencias pero vamos, no debería ser difícil encontrar información. También puedes probar en Wikipedia... igual hay algo interesante .

Saludos

Estoy seguro de que -genius habrá entendido muy, pero que muuuy poco de lo que has dicho! Jajaja, hasta a mi me ha costado. Pero bueno, es normal porqué el tema en si no es excesivamente fácil y sin tener algún tipo de conocimiento previo es complicado a bote pronto.

Mmmm, yo no era consciente del matiz este entre el ensamblador y el código máquina. Siempre había creido que el código máquina eran unos y ceros. Me parece que esto ya lo discutimos una vez, hace bastante tiempo.

En fin, así que me estás diciendo que si yo escribo un programa en ensamblador, el compilador (nasm por ejemplo, - que no podría asegurar que fuera un compilador-) modificaría mi código fuente para que se adaptara al ensamblador exacto del procesador?

Saludos y gracias por la corrección!

Lo que hace NASM con un codigo fuente en ASM es producir el binario entendible para el procesador.

Es bastante trivial pasar de ASM a ejecutable (binario). Intervienen Opcodes y traduccion de etiquetas (las llamadas con CALL tambien).

Pero sobre la pregunta original de -genius-, poniendo el caso de gcc, gcc primero traduce a ASM y luego linka produciendo el ejecutable. Otros compiladores de C probablemente produciran codigo ejecutable directamente, sin pasar por el paso de traducir a ASM.

En resumen.

Alto nivel + Compilacion = ASM (codigo objeto)
ASM + linkado = ejecutable

Pasar de ASM a codigo ejecutable es trivial. Solo hay que traducir las etiquetas (las llamadas a las funciones con CALL tambien, no solo los saltos), como habia comentado Tuxed.

Te recomiendaria el capitulo 2 del Introduction to Reverse Engineering Software, sobre todo si quieres ver como se hace en otros lenguajes como Java.

Suerte,

hola foro...

gracias por su ayuda muchas gracias... estoy ojeando el libro y es buenisimo
y explica excelente gracias nuevamente.

gracias

Por otro lado, intenta fijarte un poco más cuando escribas e intenta hacer menos faltas. Así nos entenderemos mejor todos. Aquí, somos un poco más quisquillosos que en otros sitios con este tema.

Aunque sea off-topic creo que es importante recordarlo. La ortografía es fundamental y unos posts con faltas (por ejemplo saver) echan mucho/muchísimo para atrás a varias personas de este foro. De hecho varias de ellas son de las que más saben, así que te estarías perdiendo sus respuestas.

Por otro lado te recomiendo que cuides la composición del post, está bastante mal escrito y da la impresión de que piensas algo como:

escribo rápido sin cuidar ni revisar el post y que me respondan, total no les cuesta nada.

Lo siento si me equivoco en mi apreciación, pero mucha gente de aquí trabaja y el resto estudia y tiene mil cosas que hacer. Te recomiendo que cuides mucho la presentación del post, así la gente será más propensa a responder.

Por favor tenlo en cuenta.
Un saludo

Lo de pasar de ensamblador a binario lo tengo claro. Tal y como tu dices, es una cosa, más o menos, trivial.

Lo que no veo es el paso que comenta TuXeD de ensamblador, digamos general, a el ensamblador específico del procesador.


vlan, no sabes lo que me acabas de descubrir. Dios mio! La web que has enganchado es espectacular. La estoy examinando a fondo. Y todos sus links... Como la especie de CTF internacional que tienen montada! Gracias!

Creo que TuXeD se refiere que el compilador traduce a código máquina, es decir, 1s y 0s (como bien dices) pero que los debuggers nos muestran el código en ensamblador para que nos sea más amigable. Y respecto a la relación 1 a 1 que ha comentado querrá decir que un MOVE es igual a la palabra de control de 0s y 1s que genera las correspondientes señales de control. Espero no equivocarme y resolver tu dudilla NewLog!

Lo que no veo es el paso que comenta TuXeD de ensamblador, digamos general, a el ensamblador específico del procesador.

Vale, se me ha ido la olla. He vuelto a releer su post y he visto que no quería decir lo que he comentado. El quería decir que el compilador pasa de código de alto nivel a código máquina directamente. Y este código máquina sólo es una 'simple' traducción de los opcodes, registros y demás. Todo claro.

En fin, va bien saber que el gcc hace los dos pasos.

Saludos!

Si, en realidad son una serie de pasos que nos van acercando cada vez mas a lo que queremos obtener.
Recuerdo que en los ensambladores para dos había algunos que constaban de 3 ó 4 programas que tenías que ejecutar tu mismo,
en el orden correcto y cuidando de que no hubiera errores antes de lanzar el siguiente.
Algunos contenian los mismos programas pero automatizaban el proceso, por lo que tu solo tenías que ordenar "compilame eso".
Los compiladores de hoy han heredado esa simplificacion con lo que se crea la ilusión de que es un solo paso o un solo proceso.


A -Genius- : No se si te lo han dicho aún, entre regañina y regañina por la ortografía, - y tienen razón, hay que cuidar lo que se ofrece a los otros -, pero
bienvenido al foro .

saludos y gracias

Bueno gracias por los regaños, asi cuido mas lo que escribo... es que casi no tengo tiempo y me conecto solo pocos segundos pero gracias por corregirme. Me gusta, porque es con intencion de ayudarme aunque me dio un poquito de

Bueno, no te sientas mal, todos la pifiamos alguna vez, hasta los mejores. Lo importante es que una vez reportado el bug se sepa poner el parche adecuado.