2009-02-17 16 views
5

Todo lo que he leído parece implicar que construir un compilador cruzado es significativamente más difícil que construir un compilador que se dirija a la plataforma en la que se ejecuta. ¿Es esto cierto? Si es así, ¿por qué? Parece que generar código ensamblador y llamadas al sistema para una plataforma arbitraria no debería ser más difícil que generar ese código y llamadas al sistema para la plataforma en la que se ejecuta el compilador, pero tal vez estoy siendo ingenuo.¿Por qué es más difícil construir un compilador cruzado que compilar un compilador común?

+0

Al construir, ¿quiere decir "programación" o "compilación"? – flodin

+0

Sé interesante saber lo que has leído. Está mal :-) –

Respuesta

0

"la construcción de un compilador cruzado se significativamente más difícil que construir un compilador que se dirija a la plataforma en la que se ejecuta ".

El problema existe debido a la forma en que se crean y acceden las bibliotecas.

En la situación normal, todas las bibliotecas están ubicadas en un lugar específico y son utilizadas por todas las aplicaciones de ese sistema. Todos los mecanismos de compilación y software asumen la ubicación de las bibliotecas. los archivos make, compiladores, etc. dependen de la idea de que pueden ir a un lugar específico y encontrar lo que necesitan.

Sin embargo, en el caso de compilación cruzada, el compilador cruzado, los archivos, etc. no pueden hacer estas suposiciones; si lo hacen, vincularán las bibliotecas incorrectas.

Así que realmente se debe al hecho de que los desarrolladores hicieron ciertas suposiciones desde el principio, y estamos atrapados con eso.

Se hace más difícil cuando se están creando sistemas de archivos raíz, ya que Unix solo conoce un sistema de archivos raíz. Cuando construye otro sistema de archivos raíz, debe crear un entorno especial que le permita manipularlo sin afectar el sistema de archivos raíz real.

-Adam

0

¿Es posible que esté viendo un caso específico como 'compilar GCC como compilador cruzado', donde 'compilar' significa 'compilar' en lugar de 'escribir'?

Eso podría ser más difícil debido a problemas relacionados con las bibliotecas: para el compilador cruzado necesita bibliotecas para la plataforma de destino. Para el compilador "nativo" (es decir, no cruzado), claramente ya tiene bibliotecas de destino.

Estoy con usted en la 'creación de un generador de código' siendo los mismos aspectos - o al menos más afectados por la arquitectura del procesador de destino que por donde se ejecuta el compilador.

Y hay situaciones claras en las que un compilador cruzado es mucho más fácil que uno no cruzado. Creo que un compilador C++ alojado en 8051 sería un trabajo duro, independientemente de la plataforma a la que se dirija.

1

Esto no tiene por qué ser más difícil, pero puede depender de la arquitectura del compilador.

Un compilador no solo está traduciendo el código fuente en ASM y llamadas al sistema. También está integrando el código de ayuda preexistente en los archivos generados. Este es un código que incluye código de inicio, preámbulo de funciones, parte de la API apilable, etc.

En un compilador normal C1 para la plataforma A basada en la plataforma A, el compilador original C0 puede compilar C1 y su ayudante código (para A, ya que C0 apunta a A) directamente.

En un C2 compilador cruzado de la plataforma B desarrollado sobre la plataforma A, el C0 compilador original, primero debe construir una versión especial de C2 que no necesita el código ayudante (porque el código ayudante es para B, mientras que C0 se dirige a A), debe ejecutar C2 para generar el código de ayuda . Dependiendo del compilador, puede que tenga que generar una segunda versión de C2 que incluya el código de ayuda .

El acto de compilar la versión limitada de C2, sin código auxiliar es la inicialización.

0

Estas respuestas para la siguiente pregunta pueden ayudarlo a comprender por qué esto sería difícil.

Why can't we create programs cross-platforms these days?

Siento que todo se reduce a diferentes sistemas operativos llamando nativa IO de diferentes maneras. Para compilar un compilador independiente de la plataforma, tendrá que saber exactamente cómo funciona todo lo esencial y, básicamente, construir un sistema operativo.

[Voy a actualizar cuando llegue a casa ya que tengo que salir de trabajo ahora]

+0

No estoy de acuerdo con esto. Si tuviera un compilador escrito de forma portátil, por ejemplo ansi-C, podría compilarlo fácilmente en cualquier plataforma que tuviera un compilador ansi-c. ¿Cómo podría influir IO en él, y qué tiene que ver con la construcción de un sistema operativo? – patros

+0

A menos que esté hablando de vincular/archivar, pero eso es un juego completamente diferente. – patros

1

Muchos compiladores cruzados tienen múltiples objetivos.Creo que, en general, un compilador de múltiples objetivos es mucho más difícil que un único compilador de destino, y todos los compiladores de múltiples objetivos son, por definición, compiladores cruzados. Por lo tanto, muchos compiladores cruzados son mucho más complejos que los compiladores no cruzados.

Escribir un compilador en la plataforma A que compila el código sólo para la plataforma B no debería, en principio, ser más difícil que escribir un compilador en la plataforma A que compila solamente para la plataforma A.

+0

Esa es una lógica defectuosa ya que no es lógica porque comienza con 'Creo'. No hay explicación de por qué un compilador de múltiples objetivos es mucho más difícil también. –

+1

Pensé que era bastante obvio ... necesitas varios binarizadores, uno para cada objetivo. También necesita asegurarse de que está representando los datos internamente de una manera que funcionará no solo para un conjunto de instrucciones, sino potencialmente múltiples conjuntos de instrucciones muy diferentes. – patros

+0

Un compilador dirigido a otra plataforma necesita manejar solo una plataforma, a la que se dirige. – Potatoswatter

1

La construcción de un compilador cruzado es duro sólo si no se le ocurre a usted que es posible que desee compilación cruzada. Lo mismo es cierto, curiosamente, de ensambladores, enlazadores y depuradores. Todo lo que necesita hacer es recordar crear una abstracción explícita para representar lo que sabe sobre la máquina de destino.

Para obtener un ejemplo de un compilador cruzado bien documentado y bien documentado, consulte lcc. Para leer sobre el diseño de un depurador cruzado, hay un conference paper y un doctoral dissertation. El código puede ser descargable; No estoy seguro.

1

Éstos son algunos de los temas que he encontrado trabajando con GCC compilación cruzada:

  • Tienes que tener algunos de los archivos del sistema desde el sistema de destino presentes en el sistema host (es decir, un sysroot) para enlazar.

  • Algunos lenguajes requieren que las cosas se evalúen en tiempo de compilación en lugar de en tiempo de ejecución; además, algunas optimizaciones dan como resultado la evaluación de cosas en tiempo de compilación que se evaluarían (en el caso no optimizado) en tiempo de ejecución. Cuando el destino tiene tipos numéricos que no están presentes en el sistema host, puede ser complicado obtener la misma respuesta en los casos de tiempo de compilación y en tiempo de ejecución.

  • Las pruebas pueden ser un poquito más molestas. Debe tener dos sistemas y una forma de transferir el programa de uno a otro.

Realmente, eso es todo por los problemas generales con los que me he encontrado.

Cuestiones relacionadas