emcc — Online w chmurze

PROGRAM:

IMIĘ

emcc — nakładka na kompilator Emscripten

OPIS

plik emcc [opcje]...

Większość normalna gcc/g++ Opcje będzie praca, dla przykład:
--help Wyświetl te informacje

--wersja
Wyświetl informacje o wersji kompilatora

Opcje że jest zmodyfikowano or nowa in emcc zawierać:
-O0 Brak optymalizacji (domyślnie)

-O1 Proste optymalizacje, w tym asm.js, LLVM -O1 optymalizacje i brak czasu wykonywania
asercje lub przechwytywanie wyjątków C++ (aby ponownie włączyć przechwytywanie wyjątków C++, użyj -s
DISABLE_EXCEPTION_CATCHING=0 ). (Aby uzyskać szczegółowe informacje na temat wpływu różnych opt
poziomy, patrz apply_opt_level() w tools/shared.py, a także src/settings.js.) Uwaga:
Optymalizacje są wykonywane tylko podczas kompilacji do JavaScript, a nie do wersji pośredniej
kod bitowy, *chyba że* budujesz z EMCC_OPTIMIZE_NORMALLY=1 (niezalecane, chyba że
wiesz co robisz!)

-O2 As -O1, plus relooper (odtwarzanie pętli), LLVM -O2 optymalizacje i

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, plus niebezpieczne optymalizacje, które mogą zepsuć wygenerowany kod! To dodaje

-s FORCE_ALIGNED_MEMORY=1 -s PODWÓJNY_TRYB=0 -s PRECISE_I64_MATH=0 --zamknięcie 1
--llvm-lto 1

To wcale nie jest zalecane. Lepszym pomysłem jest wypróbowanie każdego z nich osobno
góry -O2 aby zobaczyć, co działa. Zobacz wiki i src/settings.js (dla -s opcje)
po więcej informacji.

-s OPCJA=WARTOŚĆ
Opcja generowania kodu JavaScript przekazywana do kompilatora emscripten. Dla
dostępne opcje, zobacz src/settings.js Zauważ, że w przypadku opcji, które są listami, ty
na przykład potrzebujesz cudzysłowów w większości powłok

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

or

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

(bez zewnętrznych „s w żadnym z nich, wystąpiłby błąd)

Możesz także określić plik, z którego wartość zostanie odczytana, np.

-s DEAD_FUNCTIONS=@/ścieżka/do/pliku

Zawartość /ścieżka/do/pliku zostanie odczytany, przeanalizowany JSON. i ustawiony na DEAD_FUNCTIONS
(więc plik może zawierać

["_funkcja1", "funkcja2"]

). Pamiętaj, że ścieżka musi być bezwzględna, a nie względna.

-g Użyj informacji debugowania. Pamiętaj, że potrzebujesz tego podczas ostatniej fazy kompilacji od
bitcode do JavaScript, w przeciwnym razie usuniemy go domyślnie w -O1 i powyżej. W
-O0, numery linii zostaną pokazane w wygenerowanym kodzie. W -O1 i wyżej,
optymalizator usuwa te komentarze. Ta flaga ma jednak skutek
wyłączenie wszystkiego, co powoduje zniekształcenie lub zminimalizowanie nazwy (zamknięcie lub
zarejestrować przepustkę).

--wpisane-tablice
0: Brak tablic o typie 1: Tablice o typie równoległym 2: Tablice o typie wspólnym (podobnym do C)
(Domyślne)

--llvm-opts
0: Brak optymalizacji LLVM (domyślnie w -O0) 1: -O1 Optymalizacje LLVM (domyślnie w
-O1) 2: -O2 Optymalizacje LLVM 3: -O3 Optymalizacje LLVM (domyślnie w -O2+)

--llvm-lto
0: Brak LLVM LTO (domyślnie w -O2 i poniżej) 1: LLVM LTO (domyślnie w -O3) Uwaga: Jeśli
Optymalizacje LLVM nie są uruchamiane (patrz --llvm-opts), ustawienie tego na 1 nie ma żadnego efektu.

--zamknięcie
0: Brak kompilatora zamknięcia (domyślnie w -O2 i poniżej) 1: Uruchom kompilator zamknięcia. Ten
znacznie zmniejsza rozmiar kodu i może w niektórych przypadkach zwiększyć szybkość działania (chociaż
może wystąpić również sytuacja odwrotna). Pamiętaj, że uruchomienie zajmuje trochę czasu i może wymagać trochę czasu
zmiany w kodzie. Jest to domyślnie uruchamiane w -O3.

W trybie asm.js zamknięcie będzie używane tylko w kodzie „powłoki” wokół skompilowanego
code (skompilowany kod zostanie przetworzony przez niestandardowy minifikator asm.js).

Uwaga: jeśli kompilator zamknięcia trafi na brak pamięci, spróbuj dostosować JAVA_HEAP_SIZE w
środowiska (na przykład do 4096 m dla 4 GB).

--js-transformacja
zostanie wywołana w wygenerowanym kodzie przed jego optymalizacją. To pozwala
modyfikować JavaScript, na przykład dodając kod lub usuwając go w pewien sposób
że modyfikacje te zostaną zoptymalizowane wraz z wygenerowanym kodem
odpowiednio. zostanie wywołana z nazwą pliku wygenerowanego kodu jako a
parametr; aby zmodyfikować kod, możesz odczytać oryginalne dane, a następnie dołączyć do nich
lub nadpisz go zmodyfikowanymi danymi. jest interpretowany jako oddzielony spacją
listę argumentów, np. „python processor.py” spowoduje błąd python
skrypt do uruchomienia.

--pre-js
Plik, którego zawartość jest dodawana przed wygenerowanym kodem. Robi się to *przed*
optymalizacja, więc zostanie poprawnie zminimalizowana, jeśli zostanie uruchomiony kompilator zamknięcia.

--post-js
Plik, którego zawartość jest dodawana po wygenerowanym kodzie Odbywa się to *przed*
optymalizacja, więc zostanie poprawnie zminimalizowana, jeśli zostanie uruchomiony kompilator zamknięcia.

--embed-plik
Plik do osadzenia w wygenerowanym JavaScript. Skompilowany kod będzie mógł
uzyskaj dostęp do pliku w bieżącym katalogu o tej samej nazwie, co podana tutaj. Więc jeśli
ty robisz --embed-plik dir/file.dat, to (1) dir/file.dat musi istnieć względem
gdzie uruchamiasz emcc, i (2) twój skompilowany kod będzie mógł znaleźć plik według
czytając tę ​​samą ścieżkę, dir/file.dat. Jeśli katalog jest przekazywany tutaj, jego cała
zawartość zostanie osadzona.

--preload-plik
Plik do wstępnego załadowania przed asynchronicznym uruchomieniem skompilowanego kodu. W przeciwnym razie
podobnego do --embed-plik, z wyjątkiem tego, że ta opcja jest istotna tylko podczas generowania
HTML (wykorzystuje asynchroniczne binarne XHR) lub JS, który będzie używany na stronie internetowej. Jeśli
katalog zostanie przekazany tutaj, cała jego zawartość zostanie wstępnie załadowana. Wstępnie załadowane pliki
są przechowywane w nazwa_pliku.data, gdzie nazwa_pliku.html jest głównym plikiem, który kompilujesz
Do. Aby uruchomić kod, będziesz potrzebować zarówno pliku .html, jak i pliku .data.

emcc uruchamia tools/file_packager.py, aby wykonać faktyczne pakowanie osadzonych i
wstępnie załadowane pliki. Jeśli chcesz, możesz samodzielnie uruchomić program pakujący pliki, patrz dokumenty
wewnątrz tego pliku. Następnie powinieneś umieścić dane wyjściowe programu pakującego pliki w pliku emcc
--pre-js, aby wykonywał się przed głównym skompilowanym kodem (lub uruchamiał go przed in
jakiś inny sposób).

--kompresja
Kompresuj zarówno skompilowany kod, jak i osadzone/wstępnie załadowane pliki. powinno być
potroić,

, ,

gdzie native_encoder to natywny plik wykonywalny, który kompresuje standardowe wejście do standardowego wyjścia (
najprostszy możliwy interfejs), js_decoder to plik JavaScript, który implementuje a
decoder, a nazwa_js to nazwa funkcji do wywołania w pliku dekodera (który
powinien otrzymać tablicę/wpisaną tablicę i zwrócić tablicę/wpisaną tablicę. Kompresja
działa tylko podczas generowania kodu HTML. Gdy kompresja jest włączona, wszystkie pola określone jako
wstępnie załadowane są skompresowane w jednym dużym archiwum, które ma taką samą nazwę jak plik
wyjście HTML, ale z sufiksem .data.compress

--minimalizuj
0: Nie minifikuj białych znaków wygenerowanego kodu JavaScript (domyślnie w -O0, -O1, albo jeśli
-g Jest używane)

1: Minifikuj wygenerowane JavaScript

białe znaki (domyślnie w -O2+, zakładając -g nie jest używany)

--podział
Dzieli wynikowy plik javascript na części, aby ułatwić debugowanie. Ta opcja
działa tylko wtedy, gdy generowany jest JavaScript (target -o js). Pliki z funkcją
deklaracje muszą być ładowane przed głównym plikiem po wykonaniu.

Bez opcji „-g”:

Tworzy pliki z deklaracjami funkcji do podanego rozmiaru z sufiksem
„_functions.partxxx.js” oraz plik główny z rozszerzeniem „.js”.

Z opcją „-g”:

Odtwarza strukturę katalogów plików źródłowych C i przechowuje funkcję
deklaracje w odpowiednich plikach C z przyrostkiem „.js”. Jeśli taki plik
przekroczy podany rozmiar, tworzone są pliki z rozszerzeniem „.partxxx.js”. Główny
plik znajduje się w katalogu podstawowym i ma sufiks „.js”.

--wiązać Kompiluje kod źródłowy przy użyciu metody powiązań "embind", która łączy C/C++
i JS.

--ignore-dynamiczne-łączenie Zwykle emcc traktuje dynamiczne łączenie jak
łączenie statyczne, poprzez łączenie kodu z biblioteki dynamicznej. To się nie powiedzie, jeśli
ta sama biblioteka dynamiczna jest połączona więcej niż jeden raz. Dzięki tej opcji dynamiczne łączenie
jest ignorowany, co pozwala systemowi kompilacji kontynuować bez błędów. Jednak ty
będziesz musiał później ręcznie połączyć się z udostępnionymi bibliotekami.

--shell-plik
Nazwa ścieżki do szkieletowego pliku HTML używanego podczas generowania danych wyjściowych HTML. Muszla
używany plik musi zawierać ten token: {{{ SCRIPT_CODE }}} Zauważ, że this
argument jest ignorowany, jeśli cel inny niż HTML jest określony przy użyciu metody -o opcja.

--js-biblioteka
Biblioteka JavaScript, której można używać oprócz tych z src/library_* Emscriptena

-v Włącza szczegółowe dane wyjściowe. To przejdzie -v do Clang, a także włącz EMCC_DEBUG
szczegóły operacji emcc

--jcache
Użyj pamięci podręcznej JavaScript. To jest domyślnie wyłączone. Po włączeniu emcc będzie przechowywać
wyniki kompilacji w pamięci podręcznej i sprawdź pamięć podręczną podczas późniejszej kompilacji,
coś w rodzaju tego, co robi ccache. Pozwala to na przyrostowe kompilacje - tam, gdzie jesteś
skompilować duży program, ale zmodyfikować tylko niewielką jego część - aby był znacznie szybszy
(kosztem większej liczby dyskowych operacji we/wy dla dostępu do pamięci podręcznej). Pamiętaj, że musisz włączyć
--jcache zarówno do ładowania, jak i zapisywania danych, więc musisz ją włączyć w pełnej kompilacji
aby przyspieszyć późniejszą kompilację przyrostową (w której również ją włączysz).

Buforowanie działa oddzielnie na 4 częściach kompilacji: 'pre' czyli typy i globalna
zmienne; informacja ta jest następnie wprowadzana do „funkcji”, które są funkcjami (które
zrównoleglamy), a następnie „post”, który dodaje końcowe informacje na podstawie
funkcje (np. czy potrzebujemy kodu wsparcia long64). Wreszcie są „jsfuncs”.
Optymalizacje na poziomie JavaScript. Każda z 4 części może być buforowana oddzielnie, ale
zauważ, że mogą one wpływać na siebie nawzajem: Jeśli ponownie skompilujesz pojedynczy plik C++, który
zmienia zmienną globalną - np. dodaje, usuwa lub modyfikuje zmienną globalną
dodając printf lub dodając znacznik czasu kompilacji, wtedy „pre” nie może być
ładowane z pamięci podręcznej. A ponieważ dane wyjściowe „pre” są wysyłane do „funks” i „post”, oni
również zostanie unieważniony, a tylko „jsfuncs” zostaną zapisane w pamięci podręcznej. Więc unikaj modyfikacji
globals, aby buforowanie działało w pełni.

Aby obejść problem wspomniany w poprzednim akapicie, możesz użyć

emscripten_jcache_printf

podczas dodawania debugowania printfs do kodu. Ta funkcja jest specjalnie przetworzona tak
że nie tworzy stałego ciągu globalnego dla swojego pierwszego argumentu. Widzieć
emscripten.h, aby uzyskać więcej informacji. Pamiętaj w szczególności, że musisz już mieć
wywołaj tę funkcję w swoim kodzie * przed * dodaniem jednej i wykonaniem przyrostu
build, więc dodanie odniesienia zewnętrznego (również właściwości globalnej) nie
unieważnić wszystko.

Pamiętaj, że powinieneś użyć -g podczas etapu łączenia (kod bitowy do JS), dla jcache do
działa (w przeciwnym razie minifikacja JS może to zmylić).

--Wyczyść pamięć podręczną
Ręcznie czyści pamięć podręczną skompilowanych bibliotek systemowych emscripten (libc++,
libc++abi, libc). Zwykle jest to obsługiwane automatycznie, ale jeśli zaktualizujesz llvm
w miejscu (zamiast mieć inny katalog dla nowej wersji), buforowanie
mechanizm może się pomylić. Wyczyszczenie pamięci podręcznej może rozwiązać dziwne problemy związane z
niezgodności z pamięcią podręczną, takie jak brak połączenia clang z plikami bibliotek. To także
czyści inne buforowane dane, takie jak jcache i załadowany relooper. Po
pamięć podręczna zostanie wyczyszczona, proces zakończy się.

--zapisz-bc PATH
Podczas kompilacji do JavaScript lub HTML ta opcja zapisze kopię kodu bitowego
do określonej ścieżki. Kod bitowy będzie zawierał wszystkie łączone pliki, w tym
bibliotek standardowych i po wszelkich optymalizacjach czasu łącza (jeśli takie istnieją).

--pamięć-plik-init
Jeśli jest włączony, generujemy osobny plik inicjujący pamięć. To jest bardziej wydajne
niż przechowywanie danych inicjujących pamięć osadzonych w JavaScript jako tekst.
(domyślnie jest wyłączone)

Plik docelowy, jeśli został określony (-o ), określa, co zostanie wygenerowane:

.js
JAVASCRIPT

.html
HTML z osadzonym JavaScriptem

.pne
Kod bitowy LLVM (domyślnie)

.o
Kod bitowy LLVM (taki sam jak .bc)

(Zauważ, że jeśli --pamięć-plik-init jest używany, to oprócz pliku .js lub .html
wygenerowany, pojawi się również plik .mem.)

Połączenia -c opcja (która mówi gcc, aby nie uruchamiała konsolidatora) spowoduje, że kod bitowy LLVM będzie
generowany, ponieważ emcc generuje JavaScript tylko na końcowym etapie tworzenia linków.

Pliki wejściowe mogą być plikami kodu źródłowego, które Clang może obsłużyć (C lub C++), LLVM
bitcode w formie binarnej lub pliki asemblera LLVM w formie czytelnej dla człowieka.

Na emcc ma wpływ kilka zmiennych środowiskowych. Aby uzyskać szczegółowe informacje, zobacz źródło emcc
(wyszukaj „os.environ”).

emcc: obsługiwane cele: kod bitowy llvm, javascript, NIE elf (autoconf lubi widzieć elfa
powyżej, aby włączyć obsługę obiektów udostępnionych)

PRAWA AUTORSKIE

Copyright © 2013 autorzy Emscripten (patrz AUTORZY.txt) To jest darmowe i open source
oprogramowanie na licencji MIT. NIE ma gwarancji; nawet dla HANDLOWEJ lub
PRZYDATNOŚĆ DO OKREŚLONEGO CELU.

Korzystaj z emcc online, korzystając z usług onworks.net