mikrocontroller.net

Forum: Compiler & IDEs Wie Prozessor/OS unspezifisch kann ich mein C Programm compilieren


Autor: Felix (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wie die Überschrift schon erahnen läßt wie speziell muß/ kann ich mein 
Programm compilieren. Also ich arbeite auf einem Intel/Ubuntu System. 
Wenn ich mit gcc mein C Programm compiliere muß ich es z.b. für ein 
Arm/Ubuntu System neu compilieren. Wenn ich nun mein Programm auf 
möglichst vielen Prozessoren laufen lassen will könnte ich es natürlich 
mittels Cross Compiler für jede OS/Prozessor kombination neu 
kompilieren. Ich vermute mal stark dass ich für jedes OS eine Version 
kompilieren muß. Aber wenn ich z.B. ein Windows Programm anschaue 
bekomme ich nicht x exe-files für jeden Prozessortyp. Wohingegen ich in 
Linux scheinbar spezieller sein muss/kann da die Packages speziel auf 
Prozessor und Version abgestimmt sind bzw ich den source code mittells 
make/gcc für meinen Prozessor compilieren muss/kann. Die Frage ist nur 
rein informativ etwas was ich mich schon länger gefragt habe. Ich habe 
deshalb kein konkretes Beispielprogramm was ich anführen könnte. Aber 
wäre toll wenn jemand etwas auch nur zu teilen meiner Frage sagen könnte

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die prozessorfamilie muss binärkompatibel sein, also den selben 
instructioncode verstehen. Bei pc os sind das alle intel/ amd 
orozessoren mit x86 oder IA32 und ähnlicher prozessorarchtektur. Ferner 
muss die benutzte API und die gelinkte runtime zum OS passen

https://de.m.wikipedia.org/wiki/Cygwin

https://de.m.wikipedia.org/wiki/IA-32

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch Cross-Compiler für Arm unter Windows. Da bekommt man dann 
auch für jede Architektur ein eigenes Exe. Das heisst dann nicht Exe 
sondern (z.B. bei meinem NXP-Cross Compiler) .bin .
Ist also letztendlich das gleiche unter Windows.

Unter Linux kann man sich mit file anschauen, für welche Architektur ei 
Executable ist:
file xx_message
xx_message: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=0x972eae9e79e0dbe06bd64628c7bcb191bbfea088, stripped

Das Kommando wurde auf einem X86 Linux ausgeführt, das Executable ist 
allerdings für arm/32.

Autor: Daniel Abrecht (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Felix schrieb:
> Aber wenn ich z.B. ein Windows Programm anschaue
> bekomme ich nicht x exe-files für jeden Prozessortyp

Windows ist gröstenteils auch nur auf x86 und amd64 benutzbar. Es gibt 
zwar noch arm, aber dort die meisten Anwendungen nicht. x86 ist mit 
amd64 kompatibel. Eine exe Datei ist eigentlich eine art Archivdatei. 
Der Programmcode ist immer nur für eine Architektur. Ob eine exe mehrere 
Programcodes für unterschiedliche Architekturen beinhalten kann, weiss 
ich nicht, meistens sind diese aber für eine bestimmte Architektur, man 
denke an all die Programme, die eine 64-bit und eine 32-bit Version 
anbieten. Es fällt nur nicht so auf, weil Windows sowieso nur auf sehr 
wenigen CPU Architekturen funktioniert. Ich glaube MS wollte das Problem 
bei arm mal lösen, indem sie eine amd64 Emulationsschicht ins OS 
einbauen, aber ich weiss nicht was daraus geworden ist. Ich frage mich, 
ob man in arm Windows amd64 Anwendungen laufen lassen könnte, indem man 
im WSL wine für amd64 mit Qemu User Emulation laufen lässt?

Autor: Jan B. (do9jhb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Ich frage mich, ob man in arm Windows amd64 Anwendungen laufen lassen
> könnte, indem man im WSL wine für amd64 mit Qemu User Emulation laufen
> lässt?

WSL gibt es nur für AMD64 Architekturen, weil er die Linux binaries 
direkt auf dem Hostprozessor ausführt (und dann Kernel Aufrufe auf den 
Windows-Kernel umleiten). Vermutlich würde WSL auch auf ARM laufen (wenn 
MS das implementiert), dann müssten aber auch ARM binaries für Linux 
benutzt werden.

Gruß
Jan B

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Felix schrieb:
> Aber wenn ich z.B. ein Windows Programm anschaue
> bekomme ich nicht x exe-files für jeden Prozessortyp.

Da können aber verschiedene Programmme oder Programmteile für 
verschiedene Prozessoren drinstecken, denn auch X86 ist nicht gleich 
X86. 32/64 Bit-Versionen sind sowieso getrennt

Denn zwischen einem 386 und einem aktuellen Intel-Prozessor liegen schon 
Welten. All das, was der neue mehr kann, lässt sich nur mit passend 
kompilierten Programmen auch nutzen.

Oliver

: Bearbeitet durch User
Autor: Boris Ohnsorg (bohnsorg) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Gewöhn' dich dran, so ist die Welt. Es geht nicht nur um Op-Codes für 
den spezifischen Prozessor, sondern auch um Bibliotheken und 
Linking-Strategien (static/ dynamic). Ist schon ein Unterschied, auf 
Windows in eine .DLL zu fassen, als unter Linux vom Kernel gerufen zu 
werden (oder in eine .so zu greifen). Und selbst wenn du kein einziges 
#include hast, bleibt es immer dem Compiler überlassen, wie etwa 
Gleitkommaarithmetik oder Speicherallokation vorgenommen wird. Das 
kannst du sogar mit dem Füllhorn an Compiler-Paramtern steuern. Und noch 
ein Tipp: jeder Compiler hat seine Eigenheiten UND es unterscheidet sich 
sogar von Compiler-Version zu Compiler-Version.

Autor: Daniel Abrecht (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan B. schrieb:
> Daniel A. schrieb:
>> Ich frage mich, ob man in arm Windows amd64 Anwendungen laufen lassen
>> könnte, indem man im WSL wine für amd64 mit Qemu User Emulation laufen
>> lässt?
>
> WSL gibt es nur für AMD64 Architekturen.

Oh, das wusste ich noch garnicht.

> Vermutlich würde WSL auch auf ARM laufen (wenn
> MS das implementiert), dann müssten aber auch ARM binaries für Linux
> benutzt werden.

Da käme dann eben die Qemu User Emulation ins spiel. Qemu User Emulation 
ist eine unvollständige Emulation. Statt das gesammte System zu 
emulieren, werden nur die Anwendungen darauf emuliert, wodurch man 
Anwendungen anderer Architekturen auf seinem System starten kann, wie 
wenn diese nativ wären. Ich habe das aber noch nie ausprobiert, und das 
gibt es nur für Linux:
https://wiki.debian.org/QemuUserEmulation
http://nairobi-embedded.org/qemu_usermode.html

Autor: fop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder meinst Du etwa so einen "Zwischencode" wie bei Java oder .Net ?

Da wird nicht gleich in etwas Ausführbares übersetzt, sondern in einen 
Code, den weder der Programmierer noch der Prozessor versteht, welcher 
dann, wenn der Benutzer das Programm startet, durch ein weiteres 
Programm (Laufzeitumgebung) interpretiert wird.
Dadurch ist es möglich durch Austausch des Compilers verschiedene 
Sprachen zu unterstützen und durch Austausch der Laufzeitumgebung 
verschiedene Architekturen.

Autor: Felix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nee nee ich meine schon in C. Klar in höheren Programmiersprachen ist 
dass dann immer Prozessor unspezifischer. Aber ich hatte mich nur 
gefragt weil ja die Variationsmöglichkeiten riesig sind gegen die man 
sein Programm kompilieren, optimieren und testen muss. Mit der Zeit 
nimmt ja auch die Anzahl der Prozessoren zu.
> Da können aber verschiedene Programmme oder Programmteile für
> verschiedene Prozessoren drinstecken,
Klar die Binaries können natürlich dann für verschiedene Prozessoren 
sein. Dann wird natürlich auch die Größe des Programms immer größer.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Felix schrieb:
>> Aber wenn ich z.B. ein Windows Programm anschaue
>> bekomme ich nicht x exe-files für jeden Prozessortyp
>
> Windows ist gröstenteils auch nur
noch
> auf x86 und amd64 benutzbar.

NT gab's für x86, Alpha, MIPS, PowerPC und später eine Zeit lang für 
Itanium (afair Server 2003 bis 2008), aktuell gibt es neben Windows 10 
Mobile (und dessen Vorgänger Windows Phone 8/8.1) wieder WinOnARM

> Es gibt
> zwar noch arm, aber dort die meisten Anwendungen nicht.

Die könnte es geben, wenn es 1. MS gewollt hätte 2. wenn die ganzen 
Anwendungen sauber programmiert wären und 3. wenn die Anwendungen 
entsprechend überarbeitet oder neu entwickelt worden wären 1). Beim 
aktuellen Ableger/Wiederaufguss von Windows On ARM gibt's einen 
dynamischen Übersetzer, der zur Laufzeit x86 in ARM übersetzt und 
cached. Unter NT gab's für die DEC Alphas FX!32, um x86 ausführen zu 
können und etwas anders gearbeitet hat
https://en.wikipedia.org/wiki/FX!32
1) "Native code for Windows Phone 8"
https://msdn.microsoft.com/en-us/library/windows/a...

> Eine exe Datei ist eigentlich eine art Archivdatei.
> Der Programmcode ist immer nur für eine Architektur. Ob eine exe mehrere
> Programcodes für unterschiedliche Architekturen beinhalten kann, weiss
> ich nicht, meistens sind diese aber für eine bestimmte Architektur, man
> denke an all die Programme, die eine 64-bit und eine 32-bit Version
> anbieten.

Hat sich anscheinend nicht durchgesetzt. Sog. Fat Binaries gibt's nur 
auf dem Mac und Amiga, für ELF gibt's anscheinend die Erweiterung 
FatELF, die mir aber bislang noch nicht begegnet ist.
https://en.wikipedia.org/wiki/Comparison_of_execut...

> Ich frage mich,
> ob man in arm Windows amd64 Anwendungen laufen lassen könnte, indem man
> im WSL wine für amd64 mit Qemu User Emulation laufen lässt?

Qemu läuft auch ohne WSL, emulieren ohne Hardwareunterstützung will man 
eh nur sehr selten

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Felix schrieb:
> Nee nee ich meine schon in C. Klar in höheren Programmiersprachen ist
> dass dann immer Prozessor unspezifischer. Aber ich hatte mich nur
> gefragt weil ja die Variationsmöglichkeiten riesig sind gegen die man
> sein Programm kompilieren, optimieren und testen muss. Mit der Zeit
> nimmt ja auch die Anzahl der Prozessoren zu.

Weshalb Microsoft/DotNet wie auch Google/Android Techniken verwenden, 
die den abschliessenden Schritt der Übersetzung von Programmen in 
Binärcode der Zielmaschine auf die Zielmaschine selbst verlagern. In 
beiden Systemen werden Programme in einem Zwischenformat ausgeliefert 
und erst auf der Zielmaschine weiter übersetzt. Erlebt man in Windows 
nach Updates von DotNet im Form längerer CPU-Aktivität eines Prozesses 
mscorsw.exe.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Felix schrieb:
> Aber wenn ich z.B. ein Windows Programm anschaue
> bekomme ich nicht x exe-files für jeden Prozessortyp.

Was aber zur Folge haben kann, dass das Programm nur einen 
Grundbefehlsatz von anno dunnemal verwendet, Befehlserweiterungen also 
nicht nutzt. Oder zur Laufzeit abhängig vom konkreten Prozessor 
verschiedene Codevarianten verwendet. Letzteres bleibt für den Anwender 
aber unsichtbar.

> Wohingegen ich in
> Linux scheinbar spezieller sein muss/kann da die Packages speziel auf
> Prozessor und Version abgestimmt

Windows gibt es in der Breite für 2 Architekturen, 32-Bit x86 und 64-bit 
x64 (aka x86-64 oder amd64). Exoten wie IA64 und je nach Laune vom 
Microsoft auch ARM sind Randerscheinungen. Abgesehen davon definiert 
Microsoft alleine, was Windows ist.

Linux gibts für alle CPUs auf die es drauf passt. Wobei auch nicht jeder 
ARM gleich ist, weil es innerhalb der ARM Prozessoren verschiedene 
Byteorder, Floatingpoint-Unit etc gibt. Dann gibts zwar gewisse 
Library-Konventionen, aber oft benötigt man dennoch verschiedene 
Binaries oder zumindest Packages für verschiedene Distributionen. Nicht 
alles was für die Debian-Familie gebaut wird, ist auch in Redhat- oder 
Suse-Systemen einsetzbar, selbst bei gleicher CPU.

Ein Weg, das Problem zu lösen, ist Software-Distribution in Quellcode. 
Es gibt Tools, die bei der Installation einer Software das System auf 
seine Eigenheiten abklopft und damit für den Compiler vorbereitet. Der 
Entwickler kann natürlich nicht alle testen, das tun die Anwender. 
Einige fluchen dann, wenn das Ding beim "make" Fehler auswirft. Je nach 
Skill und Problem behebt er es dann selbst, informiert den 
Entwickler/Maintainer oder schmeisst es in den Müll.

Kommerzielle nicht quelloffene Software für Linux ist deshalb mitunter 
auf nur eine oder wenige Plattformen eingeschränkt. D.h. das gibts dann 
beispielsweise nur für Redhat.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.