emcc - Online nel cloud

PROGRAMMA:

NOME

emcc - Frontend del compilatore Emscripten

DESCRIZIONE

file emcc [opzioni]...

ponte normale gcc/g++ Opzioni volere lavoro, per esempio:
--Aiuto Visualizza queste informazioni

--versione
Visualizza le informazioni sulla versione del compilatore

Opzioni che sono modificato or nuovi in ecc includono:
-O0 Nessuna ottimizzazione (impostazione predefinita)

-O1 Ottimizzazioni semplici, tra cui asm.js, LLVM -O1 ottimizzazioni e nessun runtime
asserzioni o rilevamento delle eccezioni C++ (per riattivare il rilevamento delle eccezioni C++, utilizzare -s
DISABLE_EXCEPTION_CATCHING=0 ). (Per i dettagli sugli effetti dei diversi opt
livelli, vedere apply_opt_level() in tools/shared.py e anche src/settings.js.) Nota:
Le ottimizzazioni vengono eseguite solo durante la compilazione in JavaScript, non nell'intermediazione
bitcode, *a meno che* non si crei con EMCC_OPTIMIZE_NORMALLY=1 (non consigliato a meno che
Sai cosa stai facendo!)

-O2 As -O1, più il relooper (ricreazione del ciclo), LLVM -O2 ottimizzazioni, e

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, oltre a pericolose ottimizzazioni che potrebbero violare il codice generato! Questo aggiunge

-s FORCE_ALIGNED_MEMORY=1 -s MODALITÀ_DOUBLE=0 -s PRECISE_I64_MATH=0 --chiusura 1
--llvm-lto 1

Questo non è affatto raccomandato. Un'idea migliore è provare ciascuno di questi separatamente su
cima -O2 per vedere cosa funziona. Vedi il wiki e src/settings.js (per il -s opzioni)
per maggiori informazioni.

-s OPZIONE=VALORE
Opzione di generazione del codice JavaScript passata al compilatore emscripten. Per il
opzioni disponibili, vedere src/settings.js Nota che per le opzioni che sono elenchi,
necessitano di virgolette nella maggior parte delle shell, ad esempio

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

or

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

(senza la "s" esterna in nessuno di questi, otterresti un errore)

Puoi anche specificare un file da cui leggere il valore, ad esempio

-s DEAD_FUNCTIONS=@/percorso/a/file

Il contenuto di /percorso/di/file verrà letto, JSON.parsed e impostato in DEAD_FUNCTIONS
(quindi il file potrebbe contenere

["_func1", "func2"]

). Nota che il percorso deve essere assoluto, non relativo.

-g Usa le informazioni di debug. Nota che ne hai bisogno durante l'ultima fase di compilazione da
bitcode in JavaScript, altrimenti lo rimuoveremo per impostazione predefinita in -O1 e al di sopra. In
-O0, i numeri di riga verranno visualizzati nel codice generato. In -O1 e sopra, il
ottimizzatore rimuove quei commenti. Questo flag ha comunque l'effetto di
disabilitare tutto ciò che provoca la modifica o la minimizzazione del nome (chiusura o
tessera di registrazione).

--array-digitati
0: nessun array tipizzato 1: array tipizzati paralleli 2: array tipizzati condivisi (di tipo C)
(Default)

--llvm-opts
0: nessuna ottimizzazione LLVM (impostazione predefinita in -O0) 1: -O1 Ottimizzazioni LLVM (predefinito in
-O1) 2: -O2 Ottimizzazioni LLVM 3: -O3 Ottimizzazioni LLVM (predefinito in -O2+)

--llvm-lto
0: Nessun LTO LLVM (predefinito in -O2 e sotto) 1: LLVM LTO (predefinito in -O3) Nota: se
Le ottimizzazioni LLVM non vengono eseguite (vedi --llvm-opts), l'impostazione di questo su 1 non ha alcun effetto.

--chiusura
0: compilatore senza chiusura (predefinito in -O2 e sotto) 1: Esegui il compilatore di chiusura. Questo
riduce notevolmente le dimensioni del codice e in alcuni casi può aumentare la velocità di runtime (sebbene
può verificarsi anche il contrario). Tieni presente che l'esecuzione richiede tempo e potrebbe richiedere un po' di tempo
modifiche al codice. Questo è eseguito per impostazione predefinita in -O3.

In modalità asm.js, la chiusura verrà utilizzata solo sul codice 'shell' attorno al compilato
codice (il codice compilato verrà elaborato dal minifier personalizzato asm.js).

Nota: se il compilatore di chiusura raggiunge un'esaurimento della memoria, prova a regolare JAVA_HEAP_SIZE in
l'ambiente (ad esempio, a 4096 m per 4 GB).

--js-trasformare
verrà chiamato sul codice generato prima che venga ottimizzato. Questo ti permette
modificare il JavaScript, ad esempio aggiungendo del codice o rimuovendo del codice, in un certo senso
che tali modifiche saranno ottimizzate insieme al codice generato
propriamente. verrà chiamato con il nome del file del codice generato come a
parametro; per modificare il codice si possono leggere i dati originali e poi aggiungervisi
o sovrascriverlo con i dati modificati. viene interpretato come uno spazio separato
elenco di argomenti, ad esempio di "python processor.py" causerà un python
script da eseguire.

--pre-js
Un file il cui contenuto viene aggiunto prima del codice generato. Questo è fatto *prima*
ottimizzazione, quindi verrà minimizzato correttamente se viene eseguito il compilatore di chiusura.

--post-js
Un file il cui contenuto viene aggiunto dopo il codice generato Questo viene fatto *prima*
ottimizzazione, quindi verrà minimizzato correttamente se viene eseguito il compilatore di chiusura.

--embed-file
Un file da incorporare all'interno del JavaScript generato. Il codice compilato sarà in grado di
accedere al file nella directory corrente con lo stesso nome indicato qui. Quindi se
tu fai --embed-file dir/file.dat, quindi (1) dir/file.dat deve esistere relativamente a
dove esegui emcc e (2) il tuo codice compilato sarà in grado di trovare il file da
leggendo lo stesso percorso, dir/file.dat. Se una directory viene passata qui, è intera
i contenuti verranno incorporati.

--precarica-file
Un file da precaricare prima di eseguire il codice compilato in modo asincrono. Altrimenti
simile a --embed-file, tranne per il fatto che questa opzione è rilevante solo durante la generazione
HTML (usa XHR binari asincroni) o JS che verrà utilizzato in una pagina web. Se
una directory viene passata qui, il suo intero contenuto verrà precaricato. File precaricati
sono memorizzati in filename.data, dove filename.html è il file principale che stai compilando
a. Per eseguire il tuo codice, avrai bisogno sia di .html che di .data.

emcc esegue tools/file_packager.py per eseguire il pacchetto effettivo di embedded e
file precaricati. Puoi eseguire tu stesso il file packager se vuoi, vedi i documenti
all'interno di quel file. Dovresti quindi mettere l'output del file packager in un emcc
--pre-js, in modo che venga eseguito prima del codice compilato principale (o eseguito prima di in
qualche altro modo).

--compressione
Comprimi sia il codice compilato che i file incorporati/precaricati. dovrebbe essere un
triplicare,

, ,

dove native_encoder è un eseguibile nativo che comprime stdin in stdout (il
interfaccia più semplice possibile), js_decoder è un file JavaScript che implementa a
decoder e js_name è il nome della funzione da chiamare nel file del decoder (che
dovrebbe ricevere un array/array tipizzato e restituire un array/array tipizzato. Compressione
funziona solo durante la generazione di HTML. Quando la compressione è attiva, tutti i file sono specificati come
precaricati vengono compressi in un unico grande archivio, a cui viene dato lo stesso nome del
output HTML ma con suffisso .data.compress

--minimizza
0: non minimizza lo spazio bianco del JavaScript generato (predefinito in -O0, -O1, o se
-g si usa)

1: Minimizza i JavaScript generati

spazi bianchi (predefinito in -O2+, supponendo -g non è utilizzato)

--diviso
Divide il file javascript risultante in parti per facilitare il debug. Questa opzione
funziona solo se viene generato Javascript (target -o .js). File con funzione
le dichiarazioni devono essere caricate prima del file principale al momento dell'esecuzione.

Senza l'opzione "-g":

Crea file con dichiarazioni di funzione fino alla dimensione data con il suffisso
"_functions.partxxx.js" e un file principale con il suffisso ".js".

Con l'opzione "-g":

Ricrea la struttura della directory dei file sorgente C e memorizza la funzione
dichiarazioni nei rispettivi file C con il suffisso ".js". Se un tale file
supera la dimensione data, vengono creati file con il suffisso ".partxxx.js". Il principale
file risiede nella directory di base e ha il suffisso ".js".

--legamento Compila il codice sorgente utilizzando l'approccio dei binding "embind", che collega C/C++
e JS.

--ignora-collegamento-dinamico Normalmente emcc tratterà il collegamento dinamico come
collegamento statico, collegando il codice dalla libreria dinamica. Questo fallisce se il
la stessa libreria dinamica è collegata più di una volta. Con questa opzione, collegamento dinamico
viene ignorato, il che consente al sistema di compilazione di procedere senza errori. Tuttavia, tu
dovrai collegarti manualmente alle librerie condivise in un secondo momento.

--file-shell
Il nome del percorso di un file HTML scheletro utilizzato durante la generazione dell'output HTML. Il guscio
il file utilizzato deve contenere questo token al suo interno: {{{ SCRIPT_CODE }}} Nota che questo
l'argomento viene ignorato se viene specificato un target diverso da HTML utilizzando il tasto -o opzione.

--js-libreria
Una libreria JavaScript da utilizzare in aggiunta a quelle in src/library_* di Emscripten

-v Attiva l'output dettagliato. Questo passerà -v a Clang e abilita anche EMCC_DEBUG a
dettagli sulle operazioni di emcc

--jcache
Usa una cache JavaScript. Questa impostazione è disabilitata per impostazione predefinita. Quando abilitato, emcc memorizzerà
i risultati della compilazione in una cache e controllare la cache durante la compilazione successiva,
qualcosa di simile a quello che fa ccache. Ciò consente build incrementali - dove sei
compilando un grande programma ma modificandone solo una piccola parte - per essere molto più veloce
(al costo di più IO del disco per gli accessi alla cache). Nota che devi abilitare
--jcache sia per il caricamento che per il salvataggio dei dati, quindi è necessario abilitarlo su una build completa
per una successiva build incrementale (dove lo abiliti anche tu) da accelerare.

La memorizzazione nella cache funziona separatamente su 4 parti della compilazione: 'pre' che è tipi e globale
variabili; quell'informazione viene poi inserita in 'funcs' che sono le funzioni (che
parallelizziamo), e poi 'post' che aggiunge le informazioni finali in base al
funzioni (ad esempio, abbiamo bisogno del codice di supporto long64). Infine, 'jsfuncs' sono
Ottimizzazioni a livello di JavaScript. Ciascuna delle 4 parti può essere memorizzata nella cache separatamente, ma
nota che possono influenzarsi a vicenda: se ricompili un singolo file C++ che
cambia una variabile globale - ad esempio, aggiunge, rimuove o modifica una variabile globale, diciamo
aggiungendo un printf o aggiungendo un timestamp in fase di compilazione, allora 'pre' non può essere
caricato dalla cache. E poiché l'output di "pre" viene inviato a "funcs" e "post", loro
verrà invalidato e solo 'jsfuncs' verrà memorizzato nella cache. Quindi evita di modificare
globals per consentire il funzionamento completo della cache.

Per aggirare il problema menzionato nel paragrafo precedente, puoi usare

emscripten_jcache_printf

quando aggiungi debug printfs al tuo codice. Quella funzione è appositamente preelaborata, quindi
che non crea una stringa globale costante per il suo primo argomento. Vedere
emscripten.h per maggiori dettagli. Nota in particolare che devi già avere un
chiama quella funzione nel tuo codice *prima* di aggiungerne uno e fare un incrementale
build, in modo che l'aggiunta di un riferimento esterno (anche una proprietà globale) non lo faccia
invalidare tutto.

Nota che dovresti usare -g durante la fase di collegamento (bitcode a JS), per jcache a
lavoro (altrimenti, la minimizzazione di JS può confonderlo).

--cancella-cache
Cancella manualmente la cache delle librerie di sistema emscripten compilate (libc++,
libc++abi, libc). Questo viene normalmente gestito automaticamente, ma se aggiorni llvm
sul posto (invece di avere una directory diversa per una nuova versione), la memorizzazione nella cache
meccanismo può confondersi. Svuotare la cache può risolvere strani problemi relativi a
incompatibilità della cache, come clang che non riesce a collegarsi con i file di libreria. Anche questo
cancella altri dati memorizzati nella cache come jcache e relooper bootstrap. Dopo il
cache è cancellata, questo processo verrà terminato.

--salva-bc PERCORSO
Quando si compila in JavaScript o HTML, questa opzione salverà una copia del bitcode
al percorso specificato. Il codice bit includerà tutti i file collegati, incluso
librerie standard e dopo eventuali ottimizzazioni del tempo di collegamento (se presenti).

--file-init-memoria
Se attivo, generiamo un file di inizializzazione della memoria separato. Questo è più efficiente
piuttosto che memorizzare i dati di inizializzazione della memoria incorporati all'interno di JavaScript come testo.
(l'impostazione predefinita è disattivata)

Il file di destinazione, se specificato (-o ), definisce cosa verrà generato:

.js
JavaScript

.html
HTML con JavaScript incorporato

.avanti Cristo
Codice bit LLVM (predefinito)

.o
Codice bit LLVM (uguale a .bc)

(Nota che se --file-init-memoria viene utilizzato, quindi in aggiunta a un file .js o .html che è
generato, apparirà anche un file .mem.)

I -c opzione (che dice a gcc di non eseguire il linker) farà sì che il bitcode LLVM sia
generato, poiché emcc genera JavaScript solo nella fase di collegamento finale della creazione.

I file di input possono essere file di codice sorgente che Clang può gestire (C o C++), LLVM
bitcode in formato binario o file assembly LLVM in formato leggibile.

emcc è influenzato da diverse variabili d'ambiente. Per i dettagli, visualizzare la fonte di emcc
(cercare 'os.environ').

emcc: target supportati: llvm bitcode, javascript, NOT elf (autoconf ama vedere elf
sopra per abilitare il supporto per oggetti condivisi)

COPYRIGHT

Copyright © 2013 gli autori di Emscripten (vedi AUTHORS.txt) Questo è gratuito e open source
software con licenza MIT. NON c'è garanzia; nemmeno per COMMERCIABILITA' o
IDONEITÀ PER UNO SCOPO PARTICOLARE.

Usa emcc online utilizzando i servizi onworks.net