emcc – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

emcc – Emscripten-Compiler-Frontend

BESCHREIBUNG

emcc [Optionen] Datei...

brauchen normal gcc/g++ Optionen werden wir zu arbeiten, für Beispiel:
--help Zeigen Sie diese Informationen an

--Version
Zeigt Informationen zur Compilerversion an

Optionen zur Verbesserung der Gesundheitsgerechtigkeit sind geändert or neu in emcc -System umfasst:
-O0 Keine Optimierungen (Standard)

-O1 Einfache Optimierungen, einschließlich asm.js, LLVM -O1 Optimierungen und keine Laufzeit
Zusicherungen oder das Abfangen von C++-Ausnahmen (um das Abfangen von C++-Ausnahmen wieder zu aktivieren, verwenden Sie -s
DISABLE_EXCEPTION_CATCHING=0 ). (Einzelheiten zu den Auswirkungen verschiedener Optionen finden Sie hier
(siehe apply_opt_level() in tools/shared.py und auch src/settings.js.) Hinweis:
Optimierungen werden nur bei der Kompilierung in JavaScript durchgeführt, nicht bei der Kompilierung auf mittlerem Niveau
Bitcode, *es sei denn* Sie erstellen mit EMCC_OPTIMIZE_NORMALLY=1 (nicht empfohlen, es sei denn
Du weißt, was du tust!)

-O2 As -O1, plus der Relooper (Loop-Erholung), LLVM -O2 Optimierungen und

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, plus gefährliche Optimierungen, die den generierten Code zerstören können! Dies fügt hinzu

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --Schließung 1
--llvm-lto 1

Dies wird überhaupt nicht empfohlen. Eine bessere Idee ist es, jedes davon einzeln auszuprobieren
Spitze -O2 um zu sehen, was funktioniert. Siehe das Wiki und src/settings.js (für die -s Optionen)
um mehr zu erfahren.

-s OPTION=WERT
Option zur JavaScript-Codegenerierung, die an den Emscripten-Compiler übergeben wird. Für die
Verfügbare Optionen finden Sie unter src/settings.js. Beachten Sie, dass Sie für Optionen, bei denen es sich um Listen handelt, Folgendes tun müssen
benötigen beispielsweise in den meisten Shells Anführungszeichen

-s RUNTIME_LINKED_LIBS="['liblib.so']"

or

-s "RUNTIME_LINKED_LIBS=['liblib.so']"

(Ohne die externen „s“ würden Sie eine Fehlermeldung erhalten)

Sie können auch eine Datei angeben, aus der der Wert gelesen werden soll, z. B.

-s DEAD_FUNCTIONS=@/path/to/file

Die Inhalte von /Pfad/zu/Datei wird gelesen, JSON.parsed und in DEAD_FUNCTIONS gesetzt
(damit die Datei enthalten könnte

["_func1", "func2"]

). Beachten Sie, dass der Pfad absolut und nicht relativ sein muss.

-g Verwenden Sie Debug-Informationen. Beachten Sie, dass Sie dies während der letzten Kompilierungsphase benötigen
Bitcode in JavaScript umwandeln, andernfalls entfernen wir ihn standardmäßig in -O1 und darüber. In
-O0, Zeilennummern werden im generierten Code angezeigt. In -O1 und darüber, die
Der Optimierer entfernt diese Kommentare. Dieses Flag hat jedoch die Wirkung von
Deaktivieren Sie alles, was zu einer Namensverfälschung oder -minimierung führt (Schließung oder das
Pass registrieren).

--typed-arrays
0: Keine typisierten Arrays 1: Parallele typisierte Arrays 2: Gemeinsam genutzte (C-ähnliche) typisierte Arrays
(Default)

--llvm-opts
0: Keine LLVM-Optimierungen (Standard in -O0) 1: -O1 LLVM-Optimierungen (Standard in
-O1) 2: -O2 LLVM-Optimierungen 3: -O3 LLVM-Optimierungen (Standard in -O2+)

--llvm-lto
0: Kein LLVM LTO (Standard in -O2 und darunter) 1: LLVM LTO (Standard in -O3) Hinweis: Wenn
LLVM-Optimierungen werden nicht ausgeführt (siehe --llvm-opts), hat die Einstellung auf 1 keine Auswirkung.

--Schließung
0: Kein Abschluss-Compiler (Standard in -O2 und darunter) 1: Abschluss-Compiler ausführen. Das
Reduziert die Codegröße erheblich und kann in einigen Fällen die Laufzeitgeschwindigkeit erhöhen (obwohl
das Gegenteil kann auch eintreten). Beachten Sie, dass die Ausführung einige Zeit in Anspruch nimmt und möglicherweise einige Zeit erfordert
Änderungen am Code. Dies wird standardmäßig in ausgeführt -O3.

Im asm.js-Modus wird der Abschluss nur für den „Shell“-Code rund um den kompilierten Code verwendet
Code (der kompilierte Code wird vom benutzerdefinierten asm.js-Minifier verarbeitet).

Hinweis: Wenn der Abschluss-Compiler einen Speichermangel feststellt, versuchen Sie, JAVA_HEAP_SIZE anzupassen
der Umgebung (z. B. auf 4096 m für 4 GB).

--js-transform
wird für den generierten Code aufgerufen, bevor er optimiert wird. Dies ermöglicht Ihnen
Ändern Sie das JavaScript, indem Sie beispielsweise Code hinzufügen oder Code entfernen
dass diese Änderungen zusammen mit dem generierten Code optimiert werden
richtig. wird mit dem Dateinamen des generierten Codes als aufgerufen
Parameter; Um den Code zu ändern, können Sie die Originaldaten lesen und dann daran anhängen
oder mit den geänderten Daten überschreiben. wird als durch Leerzeichen getrennt interpretiert
Liste von Argumenten, zum Beispiel, von „Python-Prozessor.py“ führt zu einem Python
Skript, das ausgeführt werden soll.

--pre-js
Eine Datei, deren Inhalt vor dem generierten Code hinzugefügt wird. Dies geschieht *vor*
Optimierung, sodass es ordnungsgemäß minimiert wird, wenn der Abschluss-Compiler ausgeführt wird.

--post-js
Eine Datei, deren Inhalt nach dem generierten Code hinzugefügt wird. Dies geschieht *vor*
Optimierung, sodass es ordnungsgemäß minimiert wird, wenn der Abschluss-Compiler ausgeführt wird.

--embed-Datei
Eine Datei zum Einbetten in das generierte JavaScript. Der kompilierte Code wird dazu in der Lage sein
Greifen Sie auf die Datei im aktuellen Verzeichnis mit demselben Namen wie hier angegeben zu. Also wenn
Sie machen --embed-Datei dir/file.dat, dann muss (1) dir/file.dat relativ zu existieren
wo Sie emcc ausführen und (2) Ihr kompilierter Code die Datei finden kann
Lesen Sie denselben Pfad, dir/file.dat. Wenn hier ein Verzeichnis übergeben wird, ist es das gesamte Verzeichnis
Inhalte werden eingebettet.

--preload-file
Eine Datei, die vorab geladen werden soll, bevor der kompilierte Code asynchron ausgeführt wird. Ansonsten
ähnlich --embed-Datei, mit der Ausnahme, dass diese Option nur beim Generieren relevant ist
HTML (es verwendet asynchrone binäre XHRs) oder JS, das in einer Webseite verwendet wird. Wenn
Hier wird ein Verzeichnis übergeben, dessen gesamter Inhalt vorgeladen wird. Vorinstallierte Dateien
werden in Dateiname.Daten gespeichert, wobei Dateiname.html die Hauptdatei ist, die Sie kompilieren
Zu. Um Ihren Code auszuführen, benötigen Sie sowohl die .html- als auch die .data-Datei.

emcc führt tools/file_packager.py aus, um die eigentliche Verpackung von eingebetteten und eingebetteten Dateien durchzuführen
vorinstallierte Dateien. Sie können den Dateipaketierer bei Bedarf selbst ausführen, siehe Dokumentation
in dieser Datei. Anschließend sollten Sie die Ausgabe des Dateipaketierers in einem EMCC ablegen
--pre-js, sodass es vor Ihrem kompilierten Hauptcode ausgeführt wird (oder es vor dem Ausführen in
auf andere Weise).

--Kompression
Komprimieren Sie sowohl den kompilierten Code als auch die eingebetteten/vorinstallierten Dateien. sollte ein sein
verdreifachen,

, ,

Dabei ist native_encoder eine native ausführbare Datei, die stdin auf stdout komprimiert (die
einfachstmögliche Schnittstelle), js_decoder ist eine JavaScript-Datei, die a implementiert
Decoder, und js_name ist der Name der Funktion, die in der Decoder-Datei aufgerufen werden soll (welche
sollte ein Array/typisiertes Array empfangen und ein Array/typisiertes Array zurückgeben. Kompression
Funktioniert nur beim Generieren von HTML. Wenn die Komprimierung aktiviert ist, werden alle angegebenen Dateien angezeigt
Die vorinstallierten Dateien werden in einem großen Archiv komprimiert, das den gleichen Namen erhält wie das
HTML ausgeben, aber mit dem Suffix .data.compress

--minify
0: Minimiert den Leerraum des generierten JavaScript nicht (Standard in -O0, -O1, oder wenn
-g wird eingesetzt)

1: Minimieren Sie die generierten JavaScripts

Leerzeichen (Standard in -O2+, vorausgesetzt -g wird nicht verwendet)

--Teilt
Teilt die resultierende Javascript-Datei in Teile auf, um das Debuggen zu erleichtern. Diese Option
Funktioniert nur, wenn Javascript generiert wird (Ziel -o .js). Dateien mit Funktion
Deklarationen müssen bei der Ausführung vor der Hauptdatei geladen werden.

Ohne „-g“-Option:

Erstellt Dateien mit Funktionsdeklarationen bis zur angegebenen Größe mit dem Suffix
„_functions.partxxx.js“ und eine Hauptdatei mit dem Suffix „.js“.

Mit der Option „-g“:

Erstellt die Verzeichnisstruktur der C-Quelldateien und Speicherfunktion neu
Deklarationen in ihren jeweiligen C-Dateien mit dem Suffix „.js“. Wenn eine solche Datei
die angegebene Größe überschreitet, werden Dateien mit der Endung „.partxxx.js“ erstellt. Das Wichtigste
Die Datei befindet sich im Basisverzeichnis und hat das Suffix „.js“.

--binden Kompiliert den Quellcode mithilfe des Bindungsansatzes „embind“, der C/C++ verbindet
und JS.

--ignore-dynamic-linking Normalerweise behandelt emcc die dynamische Verknüpfung wie folgt
Statisches Linken durch Einbinden des Codes aus der dynamischen Bibliothek. Dies schlägt fehl, wenn die
Dieselbe dynamische Bibliothek ist mehr als einmal verknüpft. Mit dieser Option erfolgt die dynamische Verlinkung
wird ignoriert, wodurch das Buildsystem ohne Fehler fortfahren kann. Aber du
Sie müssen später selbst manuell eine Verknüpfung zu den gemeinsam genutzten Bibliotheken herstellen.

--shell-file
Der Pfadname zu einer Skelett-HTML-Datei, die beim Generieren der HTML-Ausgabe verwendet wird. die Muschel
Die verwendete Datei muss dieses Token enthalten: {{{ SCRIPT_CODE }}} Beachten Sie, dass dies
Das Argument wird ignoriert, wenn mit dem ein anderes Ziel als HTML angegeben wird -o .

--js-library
Eine JavaScript-Bibliothek, die zusätzlich zu denen in Emscriptens src/library_* verwendet werden kann

-v Aktiviert die ausführliche Ausgabe. Es wird vorübergehen -v zu Clang und aktivieren Sie auch EMCC_DEBUG
Einzelheiten zum Betrieb von emcc

--jcache
Verwenden Sie einen JavaScript-Cache. Dies ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, speichert emcc
die Ergebnisse der Kompilierung in einem Cache speichern und den Cache beim späteren Kompilieren überprüfen,
So etwas wie das, was Ccache macht. Dies ermöglicht inkrementelle Builds – wo immer Sie sind
ein großes Programm kompilieren, aber nur einen kleinen Teil davon ändern – um viel schneller zu sein
(auf Kosten von mehr Festplatten-IO für Cache-Zugriffe). Beachten Sie, dass Sie es aktivieren müssen
--jcache sowohl zum Laden als auch zum Speichern von Daten, daher müssen Sie es bei einem vollständigen Build aktivieren
damit ein späterer inkrementeller Build (wo Sie ihn auch aktivieren) beschleunigt werden kann.

Das Caching funktioniert separat für vier Teile der Kompilierung: „pre“, also „Typen“ und „global“.
Variablen; Diese Informationen werden dann in „funcs“ ​​eingespeist, das sind die Funktionen (die
wir parallelisieren) und dann „posten“, was abschließende Informationen basierend auf dem hinzufügt
Funktionen (z. B. benötigen wir Long64-Unterstützungscode). Schließlich sind es „jsfuncs“.
Optimierungen auf JavaScript-Ebene. Jeder der 4 Teile kann jedoch separat zwischengespeichert werden
Beachten Sie, dass sie sich gegenseitig beeinflussen können: Wenn Sie eine einzelne C++-Datei neu kompilieren
Ändert eine globale Variable, fügt beispielsweise eine globale Variable hinzu, entfernt sie oder ändert sie
durch Hinzufügen eines printf oder durch Hinzufügen eines Zeitstempels zur Kompilierungszeit, dann kann „pre“ nicht sein
aus dem Cache geladen. Und da die Ausgabe von „pre“ an „funcs“ ​​und „post“ gesendet wird, sind sie
wird ebenfalls ungültig gemacht und nur „jsfuncs“ ​​werden zwischengespeichert. Vermeiden Sie daher Änderungen
Globals, damit das Caching vollständig funktioniert.

Um das im vorherigen Absatz erwähnte Problem zu umgehen, können Sie Folgendes verwenden:

emscripten_jcache_printf

beim Hinzufügen von Debug-PrintFS zu Ihrem Code. Diese Funktion ist daher speziell vorverarbeitet
dass es für sein erstes Argument keine konstante Zeichenfolge global erstellt. Sehen
Weitere Informationen finden Sie unter emscripten.h. Beachten Sie insbesondere, dass Sie bereits über eine verfügen müssen
Rufen Sie diese Funktion in Ihrem Code auf, *bevor* Sie eine hinzufügen und eine inkrementelle Funktion ausführen
build, so dass das Hinzufügen einer externen Referenz (auch einer globalen Eigenschaft) nicht funktioniert
alles ungültig machen.

Beachten Sie, dass Sie verwenden sollten -g während der Verknüpfungsphase (Bitcode zu JS), für Jcache zu
funktionieren (andernfalls kann die JS-Minimierung es verwirren).

--Cache leeren
Löscht manuell den Cache kompilierter Emscripten-Systembibliotheken (libc++,
libc++abi, libc). Dies geschieht normalerweise automatisch, aber wenn Sie llvm aktualisieren
direkt (anstatt ein anderes Verzeichnis für eine neue Version zu haben), das Caching
Der Mechanismus kann durcheinander geraten. Das Leeren des Caches kann seltsame Probleme im Zusammenhang mit beheben
Cache-Inkompatibilitäten, wie z. B. Clang, das keine Verknüpfung mit Bibliotheksdateien herstellen kann. Das auch
löscht andere zwischengespeicherte Daten wie den Jcache und den Bootstrapp-Relooper. Nach dem
Wenn der Cache geleert wird, wird dieser Vorgang beendet.

--save-bc PATH
Beim Kompilieren in JavaScript oder HTML speichert diese Option eine Kopie des Bitcodes
zum angegebenen Pfad. Der Bitcode umfasst alle zu verlinkenden Dateien, einschließlich
Standardbibliotheken und nach etwaigen Linkzeitoptimierungen (falls vorhanden).

--memory-init-file
Wenn diese Option aktiviert ist, generieren wir eine separate Speicherinitialisierungsdatei. Das ist effizienter
als die in JavaScript eingebetteten Speicherinitialisierungsdaten als Text zu speichern.
(Standard ist deaktiviert)

Die Zieldatei, falls angegeben (-o ), definiert, was generiert wird:

.js
JavaScript

.html
HTML mit eingebettetem JavaScript

.bc
LLVM-Bitcode (Standard)

.Ö
LLVM-Bitcode (wie .bc)

(Beachten Sie, dass wenn --memory-init-file verwendet wird, dann zusätzlich zu einer .js- oder .html-Datei
generiert, wird auch eine .mem-Datei angezeigt.)

Das -c Option (die gcc anweist, den Linker nicht auszuführen) führt dazu, dass der LLVM-Bitcode angezeigt wird
generiert, da emcc JavaScript erst in der letzten Verknüpfungsphase der Erstellung generiert.

Die Eingabedateien können entweder Quellcodedateien sein, die Clang verarbeiten kann (C oder C++), oder LLVM
Bitcode in binärer Form oder LLVM-Assemblydateien in für Menschen lesbarer Form.

emcc wird von mehreren Umgebungsvariablen beeinflusst. Weitere Informationen finden Sie in der Quelle von emcc
(Suchen Sie nach „os.environ“).

emcc: Unterstützte Ziele: LLVM-Bitcode, Javascript, NICHT Elf (Autoconf sieht gerne Elf
oben, um die Unterstützung gemeinsamer Objekte zu aktivieren)

COPYRIGHT

Copyright © 2013 die Emscripten-Autoren (siehe AUTHORS.txt) Dies ist kostenlos und Open Source
Software unter der MIT-Lizenz. Es gibt KEINE Garantie; nicht einmal für MARKTGÄNGIGKEIT oder
EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.

Nutzen Sie emcc online über die Dienste von onworks.net