elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Introducción a Git (Primera Parte)


  Mostrar Mensajes
Páginas: 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27
251  Foros Generales / Foro Libre / Re: ¿Cual es el componente del campo magnetico? en: 28 Abril 2020, 16:17 pm
En este caso osea en el caso de la fuerza electromagnética el bosón en cuestión es el fotón. Por lo tanto si así lo quieres decir esas lineas serían las interacciones entre partículas que crean el campo magnético a través de bosones.

 ;-) ;-) ;-) En verdad esperaba algo mas "el universo es asi".
Esto tiene mas sentido... ahora me pregunto que es el movimiento en si del foton que forma una interaccion.

Gracias por responder.
252  Programación / Programación General / Re: Fundamento del Ensamblaje y Linkeado de Programas en: 27 Abril 2020, 18:32 pm
No. Una referencia es cualquier miembro del código fuente que se incluyó en la tabla de símbolos. Puede ser desde una expresión, a un método, un tipo de datos complejo. La expresión será reducida y convertida (en general) a notación polaca inversa antes de hacerla consignar como lista para compilar... etc...

Esta bien. Esto lo entendi, me referia a objeto no como su definicion en el contexto de la orientacion a objetos sino como, literalmente, cualquier objeto en el codigo. Como una variable, una funcion, etcetera...

La tabla de símbolos es una tabla con estructura de árbol
Esto me lo suponia, gracias por afirmarlo.

No. Un pase no tiene nada que ver con ordenar, ni tampoco se calculan la cantidad de pases.
El número de pases es una cuestión de diseño, de la forma en que haya sido concebido el compilador para manejar el lenguaje que compila.
De hecho las operaciones que realice en uno u otro pase, es también dependiente del diseño del compilador... yo simplemente señalo la 'separación lógica' (para entenderlo), en dos fases bien claras y definidas, en un pase suele hacerse en análisis léxico (para encontrar errores con 'tokens' no reconocibles y el análisis sintáctico (para ver que aunque cada token se reconoce la propia línea tiene sentido... y se reconoce como bien formada, esto como mínimo...
Esta bien... esto me tenia un poco confundido.

Luego interviene el linker que toma todos los módulos y construye con todos el ejecutable, todavía suele proceder resolver algunas referencias como ya expliqué, aunque nuevamente dependerá del diseño, pudiera ser que el compilador haya resuelto ya las referencias y el linker simplemente ensamble todos los módulos junto y lo pase definitivamente al código intermedio o al código nativo... piensa que no hay reglas fijas... hay pasos que resolver pero cada cual diseña que pasos resuelve en que sitio y cuales en otro.
Okay con esto me queda mas claro que es un enlazador.

Tambén es frecuente que haya más de una fase de optimización del código. Aunque si son demasiadas puede sufrir demora.
Hmmmmm con que a esto se debe. Me preguntaba a que se debian esas demoras repentinas cuando hacia ciertas combinaciones especificas en mis codigos. Sobre todo cuestiones relacionadas con ciclos.


No hay nada que ordenar a no ser que te refieras a poner las cosas en su sitio...
Si, precisamente a eso me refiero.

No sé porque insistes en un 'orden'.
No orden sino ordenamiento. Como metaforicamente lo explicaste con "poner las cosas en su sitio".

Por ejemplo imagina que hay una directiva include... que coloca cierto código en una parte... pués tocará dejar hueco para realojar ese include... aunque lo general es que cuando un lenguaje admite  directivas include, hace un preprocesamiento
Con que de aqui viene el termino coprocesador de C y C++.

Respecto a lo que dices en seguida, supongo que resolvere los detalles cuando analice lo que me recomendaste revisar.

Muchas gracias por tu ayuda. Entiendo mucho mejor por que existen estos procesos y por que hay una diferencia entre ellos.
253  Foros Generales / Foro Libre / ¿Cual es el componente del campo magnetico? en: 27 Abril 2020, 17:56 pm
Definitivamente la piedra angular de la tecnologia moderna. Sin embargo ¿es tan conocido como utilizado?. Se bien que el campo magnetico ha sido bien estudiado en el pasado, especialmente por Maxwell y Faraday:

http://hermes.ffn.ub.es/luisnavarro/nuevo_maletin/Maxwell_1856_Faraday_lines_excerpt.pdf

Sin embargo, incluso luego de un modelo matematico, me parece que la pregunta mas esencial es lo menos comprobable, mas que una simple manifestacion en virtud de una facultad (como dirian varios fisicos modernos), es una cuesion de que es, mas que de como es o como funciona.

Podemos observar facilmente el fenomeno con el expermiento del polvo de hierro:



Pero sigo sin encontrar una respuesta a mi pregunta: ¿que son lineas de campo?.
Esta claro que hablamos de lineas como una representacion, como dijo Newton, del fenomeno, y no como el fenomeno en si y, sabiendo eso, ¿que es lo que realmente son? ¿una perturbacion del espacio?

Me gustaria saber lo que opinan sobre esto.

Saludos.
254  Programación / Programación General / Re: Fundamento del Ensamblaje y Linkeado de Programas en: 26 Abril 2020, 21:22 pm
Esta bien...

Hablamos entonces de referencias como -cualquier tipo de- objeto a ser localizado en el algoritmo.
Los pases son, en pocas palabras, un ordenamiento (en todo sentido) del proceso de compilacion.
y ¿como calcula el compilador el numero de pases que son necesarios, en ese caso (o cualquier otro)?
El codigo objeto es entonces mas bien informacion que codigo, que el enlazador utiliza para enlazar.

En la última fase (ya del linker) si quedare algo por hacer sería recorrer de nuevo el fichero resultante y actualizar las direcciones. El linker, se encarga además de procurrar todas las referencias externas, es decir aquellas llamadas que se harán a objetos fuera dle proyecto (librerías dll, controles d eusuario, etc...), pués deba añadir código ahí para resolver el tipo de llamada a dicha librería (algunas librerías utilizan la pila
Esto me genera un poco de confusion.
Entonces seria algo asi: el compilador se encarga del ordenamiento del algoritmo principal, en forma de "arbol" (digamos). Y el enlazador se encarga del ordenamiento de su interaccion con este exterior compuesto de librerias de enlace dinamico, librerias estaticas, etcetera. ¿no?
Y ¿es el compilador o el enlazador el que auna los algoritmos de un mismo proyecto? Por deduccion de lo anterior pensaria que es el compilador.

Uf. Cuanto necesitaba leer este articulo.
Me parece interesante que la ignorancia pueda ser una fuente de creatividad. Yo no conocia las maneras en las que se realiza esto y como consecuencia invente varias maneras de hacerlo. Me gustaria incluirlas aqui pero creo que seria demasiado off-topic. Pero va desde una locura de retornos en la pila, a simplemente el registro DX. En verdad la programacion (especialmente en ensamblador) puede convertirse en un lienzo en blanco pidiendo a gritos tu imaginacion.

Gracias por tu tiempo. Este foro es increible, en verdad  :o.
255  Programación / Programación General / Re: Fundamento del Ensamblaje y Linkeado de Programas en: 26 Abril 2020, 17:51 pm
En general no es sencillo compilar de una sola pasada, por varias razones.
Okay... entonces de aqui viene.

- Hay referencias que no se han resulto, se guardan datos intermedios y en otra fase se termina de verificar.
¿te refieres con esto a que en el proceso las direcciones varian y al mismo tiempo y por el mismo son ajustadas?

- El código es tan grande que la memoria no puede albergar todo el proyecto en memoria.
Los archivos COM, son de cuando los programas eran tan pequeñitos que cabían en un unico sector (no más de 64kb.). Eso implicaba que las direcciones podían ser consideradas absolutas, si se cargaban en un sector siendo la dirección absoluta real la dirección del sector + el desplazamiento en el sector. Eso mismo supone ciertas restricciones, a cambio de una carga más rápida (no hay que traducir las direcciones que ya tiene el COM).
Un exe, en cambio puede tener cualquier tamaño, y exige que durante la carga todas sus direcciones sean modificadas (una vez cargado en memoria), conforme al valor que contienen y al punto en memoria que fueron cargados... eso supone una cierta lentitud en la carga en memoria (el loader), a su vez se libera de ciertos rigores como el tamaño limitado o los saltos...
En fin, la diferencia básica se limita a la velocidad de carga que hoy es despreciable peroq ue en los 70-80 podría suponer una gran diferencia dada la velocidad de ejecución d elos procesadores de entonces.
Cuando la velocidad de los procesadores se disparó y el tamaño de la memoria siguió el mismo camino, los programas COM, básdicamente quedaron obsoletos (pués ya más que ventajas ofrecen restricciones)
Imagino que estamos hablando de la relacion entre la velocidad de acceso al disco y a la memoria.
Sin embargo, asi como un archivo COM es limitado por su estructura, ¿un EXE no debe ser igualmente no mayor al rango del registro de segmento de codigo? (Si vamos al caso)
 
Lo siento he tachado esa parte final, porque tú sabrás que 'cuestiones superficiales' conoces, yo no sé cuales son, y creo que nadie más que tú lo sepa... ni si son correctas o sesgadas, es asumir...sin conocimiento de causa.
Es decir, como dije cuando introduje mis preguntas, lo que tiene que decir Wikipedia (como antonomasia de las definiciones generales).

Me he tomado la molestia de buscar un hilo donde respondí varios temas a Yuki, luego abandonó el proyecto, así que ya no pude orientarle más...
He buscado el hilo, te pongo un link al mensaje específico que contesta por encima las fases de un compilador (típico). Aunque si estás interesado, te recomiendo leer todo el hilo:

https://foro.elhacker.net/foro_libre/escribiendo_un_compilador_en_vivo-t482796.0.html;msg2160676#msg2160676
De hecho me he preguntado varias veces como seria el codigo fuente de un compilador. Gracias por tu tiempo.

No suele haber tales referencias.
Y eso temia. En realidad es solo curiosidad.

 
Link es enlace, linking, es enlazar... Se trata de hacer que todos esos ficheros de código individuales sean uno solo, pero no se trata de eso solo, también (y sobretodo) se trata de otorgar las direcciones de memoria relativa dentro del código (el cargador del ejecutable durante la ejecución tomará las direcciones relativas y las transformará en direccioes absolutas en la memoria, aunque no es exactamente así...
¿Te refieres con esto, como pregunte antes, a que al momento de unir los archivos las direcciones varian y el enlazador debe encargarse de a su vez ajustarlas?

Ademas me pregunto si justamente a eso te refieres con lo que dices en seguida.

Gracias por responder.
256  Seguridad Informática / Criptografía / Re: El futuro de la criptografía en: 26 Abril 2020, 14:07 pm
A los sistemas critpograficos lo que pinturas han hecho los pintores. A pesar de las limitaciones para con las herramientas que se utilizan para emular matematicamente lo que se imagina como una forma de transformar informacion, lo unico que permanece omnipotente es la imaginacion. Para mi el critpoanalisis es fundamentalmente lo mismo que observar una pintura hasta ver las manos del pintor, y seguira siendo asi hasta que pueda expresarse (de la misma forma) el azar en una ecuacion.
257  Programación / Programación General / Fundamento del Ensamblaje y Linkeado de Programas en: 25 Abril 2020, 22:14 pm
Hola.
Echandole un vistazo a lo que tiene que decir Wikipedia acerca de esto me han quedado ciertas dudas acerca del funcionamiento, digamos, de bajo nivel del ensamblaje y linkeado de programas, en terminos generales.

¿Que es, fundamentalmente, la generacion del codigo objeto?
Facilmente en Internet puede encontrarse una variedad considerable de referencia para con este tema sin embargo lo que mas bien me pregunto es cual es el proceso preciso del compilador, tomando en cuenta que ya conozco las cuestiones mas superficiales. En verdad no pido (aunque agradeceria por añadidura) una explicacion (mas bien, resumen) de este proceso porque se que no merece un resumen. Tambien agradeceria saber en donde podria encontrar una buena referencia acerca del formato de archivo OBJ.

y, de igual manera, ¿que es, fundamentalmente, el proceso de linking?
Sin bastante que añadir, tengo basicamente la misma duda.

Como resultado de estas cuesitones, ademas tengo algunas otras preguntas:
Ya que no conozco el funcionamiento basico del proceso de linking, pido que disculpen mi ignorancia porque realmente no se si es posible linkear (¿soy el unico al que le parecen raros estos anglicismos?) un archivo COM pero, si es asi, ¿cual es la diferencia entre linkear un archivo COM y un archivo EXE? y ¿en que afecta este proceso los valores de los registros de segmento, o a los mismos en definitiva, en tiempo de ejecucion?

Gracias de antemano y saludos.
258  Programación / Programación C/C++ / Re: Llamada a una funcion en un esquema de memoria segmentada en: 25 Abril 2020, 18:13 pm
¿Qué ensamblador usas?

He utilizado dos hasta ahora: un ensamblador de un emulador del i8086 (con el cual hago los COM) y ahora, por la recomendacion de Flat Assembler, utilizo el mismo. El primero si que codifica el segmento en el parametro para la instruccion sin embargo no la instruccion como far, sino siempre como short (a menos que la especifique far, lo cual no permite entonces especificar un segmento y, a su vez, lo mismo que me tiene las orejas calientes); y el segundo no permite especificar de esa manera el segmento en definitiva.

Código
  1. dwoldISR dd ?

eso automáticamente hará far a la llamada.

Seria una cuestion de utilizar MASM o TASM. Tengo TASM para 32-bits y como es de esperarse no encontre una manera de que compile codigo para 16-bits.


Edito: acabo de descargar TASM 5 y codifica perfectamente esta instruccion y, como dijiste, deduce el tipo de llamada por el tipo de dato. Yo honestamente me sentia un poco esceptico respecto a la definicion de tipo de dato en ensamblador. Por supuesto ahora entiendo (como era evidente) que cada ensamblador tiene sus "cosillas"

Posdata: En verdad fue una buena idea hacer esta pregunta, ahora veo lo perdido que estaba. Gracias por ser parte de la linterna.


¿No será que tu ensamblador usa alguna sintaxis distinta para anteponer el registro de segmento? Me parecería extraño que simplemente no admitiera eso.

De esto sinceramente no estoy seguro, seria una cuestion de estudiarlo mejor. Sin embargo honestamente no veo muy probable que exista una manera si no es simplemente con esa nomenclatura tan (digamos) estandar.

No me viene a la mente ninguna referencia que trate expresamente sobre interrupciones. La mayoría de los libros de ensamblador trataban el tema, aunque casi siempre de forma algo superficial. Creo que esto yo lo aprendí sobre todo de algún manual viejo de Intel, pero no lo recuerdo en este momento. Si me acuerdo de algo, lo posteo.

Esta bien, muchas gracias.
259  Programación / Programación C/C++ / Re: Llamada a una funcion en un esquema de memoria segmentada en: 23 Abril 2020, 20:35 pm
¿Hiciste que DS apunte al segmento donde se encuentra dwoldISR (que, si estamos en un .COM, normalmente sería CS)? Porque como sabrás, dentro de un manejador de interrupciones no hay forma de saber de antemano los valores de los registros de segmento, salvo CS, naturalmente, así que, o apuntas a DS al segmento correcto o, más simple, agregas un override con CS:

Código
  1. call cs:dwoldISR

Acabo de darme cuenta de esto. Si lo sabia, sin embargo lo pase por alto, como dije me considero un novato interactuando con estos mecanismos. Gracias por tu ayuda, ahora funciona correctamente.

Aunque para que funcionase tuve que especificar la direccion de la llamada de manera explicita:

Código:
pushf
call far 0b7fh:1923h ; esta es la direccion del servicio de interrupcion 9 en DOS 6.22
iret

Ya que ningun ensamblador me codifica instrucciones del tipo:

Citar
call <registro de segmento>:<referencia a memoria>
(como, por ejemplo, call cs:dwoldISR)

Ademas, ¿no seria fundamentalmente el mismo problema?, es decir, igualmente, ¿no habrian de ser diferentes, al momento de ejecutarse la interrupcion, los valores de los segmentos, haciendo imposible hacer referencia a la direccion (lineal) que es correcta?


Edito: No tome en cuenta que el registro CS se modifica cuando ocurre una interrupcion al decir esto. Pido obviar esta pregunta.


Por cierto, ¿conoces alguna referencia acerca de la programacion de interrupciones? Aunque conozco la manera en la que funcionan, creo que me hace falta algo de informacion practica respecto a ello.
Saludos.
260  Programación / Programación C/C++ / Re: Llamada a una funcion en un esquema de memoria segmentada en: 21 Abril 2020, 13:51 pm
Pasa que los COM están muy limitados y una de las pocas razones para usarlos era su simpleza, que era lo que quise decir arriba, cuando comenté que los punteros far eran más simples que los near (en realidad me quería referir a los COM y los EXE, pero entre que borraba y cambiaba mi mensaje, se me quedó mezclado). Obviamente, tanto como más simples no, es sólo que incluyen el segmento y no va implícito CS, como en los far. Como sea, lo que sucede con los COM es que al ejecutarlos, se cargan en memoria tal cual están en el disco, todo en un sólo segmento, y sin las reubicaciones que tienen lugar con los EXE. Esto hacía que, entre otras cosas, fuera mucho más rápido cargar los COM, pero con desventajas, como el tener sólo un segmento. Sin embargo, no es tan simple, ya que, como había comentado antes, sí que hay formas de acceder a datos más allá, pues nada impide que cargues valores en DS ó ES, por ejemplo, pero obviamente no se puede modificar directamente a CS.

Sin embargo como comentas en seguida es posible mientras no se trate de codigo reubicable. La parte de mi programa que ejecuta esta llamada es una llamada a un ISR sin la utilizacion de la instruccion INT. Es decir, especificando de manera explicita el segmento y el desplazamiento para con el ISR. Al tener problemas con este tipo de llamadas y la codificacion de llamadas far, se me ocurrio lo siguiente:

Código:
;pushf en el caso de una llamada a ISR
push cs
push delta
push es ;segmento para con la llamada
push bx ;desplazamiento para con la misma
retf ;ultimamente resulta en lo mismo que un CALL far
delta:

Me di cuenta de que a pesar de los problemas con la instruccion CALL tipo far, los ensambladores codifican perfectamente este pequeño algoritmo (que incluye precisamente un retorno de igualmente tipo far, y funciona de maravilla).

Hace ya mucho que no programo nada en 16 bits y puede que se me escape algún detalle o me confunda en algún punto, pero en esencia así es como funciona:

Como bien intuyes, no es que el sistema operativo impida a estos archivos hacer llamadas far durante la ejecución, sino que, como normalmente éstas implican código reubicable, los linkers se quejan y no permiten generar archivos COM. Podrías intentar forzar esto usando un "truco" muy común, que es meter tú mismo los opcodes de la operación. Por ejemplo, en la parte de tu código donde quieras la llamada, usas un DB con el valor del opcode para la llamada far deseada, e inmediatamente después un par de DW con los valores de segmento y desplazamiento, si los sabes.

Dicho todo lo anterior, y respondiendo a tu última pregunta, los EXE no tienen ninguna de estas limitaciones, así que te recomiendo que no te compliques con los COM. De esta manera, puedes hacerlo desde C, y en este caso, el compilador sí que debería hacer lo que pides. E independientemente del compilador que uses, si permite generar COM, obviamente debe poder hacer EXE de 16 bits.

Lo intente de esta manera y me di cuenta de que la raiz de mi problema no yace en la llamada far sino en el codigo. Igualmente gracias por ayudarme a aclarar tantas cuestiones sobre estas llamadas, el esfuerzo de ninguna equivocacion se pierde.

El programa que estoy intentando hacer es simplemente un TSR que engancha (hook) un ISR de la BIOS a una parte del mismo. Todo funciona perfectamente hasta que retoco (tweak) el slot del ISR (el cual es la interrupcion general del teclado en la BIOS, es decir, la 09h). Desde ese momento el sistema parece dejar de reaccionar. Este es el codigo al que se "hookea" el ISR:

Código:
pushf
call far dwoldISR
iret

En dwoldISR esta almacenada la direccion original de la rutina de servicio.

En verdad no se cual es el problema realmente. Igual sera una cuestion de que siga intentandolo.
Me parecio de mala educacion hablarte del problema sin la raiz del mismo.

Aprecio tu ayuda y tu tiempo.
Saludos.
Páginas: 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines