emcc - Trực tuyến trên đám mây

CHƯƠNG TRÌNH:

TÊN

emcc - Giao diện người dùng của trình biên dịch Emscripten

MÔ TẢ

emcc [tùy chọn] tệp ...

Hầu hết bình thường gcc / g ++ lựa chọn sẽ công việc, cho thí dụ:
--Cứu giúp Hiển thị thông tin này

--phiên bản
Hiển thị thông tin phiên bản trình biên dịch

Các lựa chọn việc này đang sửa đổi or mới in emcc bao gồm:
-O0 Không có tối ưu hóa (mặc định)

-O1 Tối ưu hóa đơn giản, bao gồm asm.js, LLVM -O1 tối ưu hóa và không có thời gian chạy
xác nhận hoặc bắt ngoại lệ C ++ (để bật lại bắt ngoại lệ C ++, hãy sử dụng -s
DISABLE_EXCEPTION_CATCHING = 0). (Để biết chi tiết về ảnh hưởng của các lựa chọn khác nhau
cấp, xem apply_opt_level () trong tools / shared.py và cả src / settings.js.) Lưu ý:
Tối ưu hóa chỉ được thực hiện khi biên dịch sang JavaScript, không phải ở chế độ trung gian
mã bit, * trừ khi * bạn xây dựng với EMCC_OPTIMIZE_NORMALLY = 1 (không được khuyến nghị trừ khi
Bạn biết những gì bạn đang làm!)

-O2 As -O1, cộng với trình mở lại (giải trí vòng lặp), LLVM -O2 tối ưu hóa và

-s ALIASING_FUNCTION_POINTERS = 1

-O3 As -O2, cộng với các tối ưu hóa nguy hiểm có thể phá vỡ mã đã tạo! Điều này cho biết thêm

-s FORCE_ALIGNED_MEMORY = 1 -s DOUBLE_MODE = 0 -s PRECISE_I64_MATH = 0 --Khép kín 1
--llvm-lto 1

Điều này không được khuyến khích ở tất cả. Ý tưởng tốt hơn là thử từng cái riêng biệt trên
đầu trang của -O2 để xem những gì hoạt động. Xem wiki và src / settings.js (để biết -s tùy chọn)
để biết thêm thông tin chi tiết.

-s OPTION = VALUE
Tùy chọn tạo mã JavaScript được chuyển vào trình biên dịch emscripten. Cho
các tùy chọn có sẵn, xem src / settings.js Lưu ý rằng đối với các tùy chọn là danh sách, bạn
ví dụ: cần dấu ngoặc kép trong hầu hết các shell

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

or

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

(nếu không có "s bên ngoài trong một trong hai, bạn sẽ gặp lỗi)

Bạn cũng có thể chỉ định một tệp mà từ đó giá trị sẽ được đọc, ví dụ:

-s DEAD_FUNCTIONS = @ / path / to / file

Nội dung của / path / to / file sẽ được đọc, JSON.parsed và được đặt thành DEAD_FUNCTIONS
(vì vậy tệp có thể chứa

["_func1", "func2"]

). Lưu ý rằng đường dẫn phải tuyệt đối, không tương đối.

-g Sử dụng thông tin gỡ lỗi. Lưu ý rằng bạn cần điều này trong giai đoạn biên dịch cuối cùng từ
bitcode sang JavaScript, nếu không, chúng tôi sẽ xóa nó theo mặc định trong -O1 trở lên. Trong
-O0, số dòng sẽ được hiển thị trong mã được tạo. Trong -O1 trở lên,
trình tối ưu hóa loại bỏ những nhận xét đó. Tuy nhiên, lá cờ này có tác dụng
vô hiệu hóa bất kỳ thứ gì gây ra sự xáo trộn hoặc thu nhỏ tên (đóng hoặc
pass đăng ký).

--typed-array
0: Không có mảng được định kiểu 1: Mảng được nhập song song 2: Mảng được nhập kiểu chia sẻ (giống C)
(Default)

--llvm-opt
0: Không có tối ưu hóa LLVM (mặc định trong -O0) Năm 1: -O1 Tối ưu hóa LLVM (mặc định trong
-O1) Năm 2: -O2 Tối ưu hóa LLVM 3: -O3 Tối ưu hóa LLVM (mặc định trong -O2+)

--llvm-lto
0: Không có LLVM LTO (mặc định trong -O2 trở xuống) 1: LLVM LTO (mặc định trong -O3) Lưu ý: Nếu
Tối ưu hóa LLVM không chạy (xem --llvm-opt), cài đặt này thành 1 không có hiệu lực.

--Khép kín
0: Không có trình biên dịch đóng (mặc định trong -O2 và bên dưới) 1: Chạy trình biên dịch đóng. Điều này
làm giảm đáng kể kích thước mã và trong một số trường hợp có thể tăng tốc độ thời gian chạy (mặc dù
điều ngược lại cũng có thể xảy ra). Lưu ý rằng cần thời gian để chạy và có thể yêu cầu một số
thay đổi mã. Điều này được chạy theo mặc định trong -O3.

Trong chế độ asm.js, việc đóng sẽ chỉ được sử dụng trên mã 'shell' xung quanh biên dịch
mã (mã đã biên dịch sẽ được xử lý bởi trình thu nhỏ asm.js tùy chỉnh).

Lưu ý: Nếu trình biên dịch bao đóng bị hết bộ nhớ, hãy thử điều chỉnh JAVA_HEAP_SIZE trong
môi trường (ví dụ: đến 4096m cho 4GB).

--js-biến đổi
sẽ được gọi trên mã được tạo trước khi nó được tối ưu hóa. Điều này cho phép bạn
sửa đổi JavaScript, ví dụ như thêm một số mã hoặc xóa một số mã, theo một cách
rằng những sửa đổi đó sẽ được tối ưu hóa cùng với mã được tạo
đúng. sẽ được gọi với tên tệp của mã được tạo dưới dạng
tham số; để sửa đổi mã, bạn có thể đọc dữ liệu gốc và sau đó thêm vào
hoặc ghi đè nó bằng dữ liệu đã sửa đổi. được hiểu là một ngăn cách
danh sách các đối số, ví dụ, của "python processor.py" sẽ gây ra một trăn
tập lệnh được chạy.

--pre-js
Một tệp có nội dung được thêm vào trước mã được tạo. Điều này được thực hiện * trước khi *
tối ưu hóa, vì vậy nó sẽ được thu nhỏ đúng cách nếu trình biên dịch đóng được chạy.

--post-js
Một tệp có nội dung được thêm vào sau mã được tạo. Việc này được thực hiện * trước khi *
tối ưu hóa, vì vậy nó sẽ được thu nhỏ đúng cách nếu trình biên dịch đóng được chạy.

--embed-file
Một tệp để nhúng vào bên trong JavaScript đã tạo. Mã đã biên dịch sẽ có thể
truy cập tệp trong thư mục hiện tại có cùng tên như được cung cấp ở đây. Vì vậy nếu
bạn làm --embed-file dir / file.dat, thì (1) dir / file.dat phải tồn tại so với
nơi bạn chạy emcc và (2) mã đã biên dịch của bạn sẽ có thể tìm thấy tệp bằng
đọc cùng một đường dẫn, dir / file.dat. Nếu một thư mục được chuyển đến đây, toàn bộ
nội dung sẽ được nhúng.

--preload-tệp
Một tệp cần tải trước trước khi chạy mã đã biên dịch không đồng bộ. Nếu không thì
tương tự như --embed-file, ngoại trừ việc tùy chọn này chỉ có liên quan khi tạo
HTML (nó sử dụng XHR nhị phân không đồng bộ) hoặc JS sẽ được sử dụng trong một trang web. Nếu như
một thư mục được chuyển đến đây, toàn bộ nội dung của nó sẽ được tải trước. Các tệp được tải trước
được lưu trữ trong filename.data, trong đó filename.html là tệp chính mà bạn đang biên dịch
đến. Để chạy mã của bạn, bạn sẽ cần cả .html và .data.

emcc chạy các công cụ / file_packager.py để thực hiện đóng gói thực tế của
các tệp được tải trước. Bạn có thể tự chạy trình đóng gói tệp nếu muốn, xem tài liệu
bên trong tệp đó. Sau đó, bạn nên đặt đầu ra của trình đóng gói tệp trong một emcc
--pre-js, để nó thực thi trước mã được biên dịch chính của bạn (hoặc chạy trước đó trong
một số cách khác).

--nén
Nén cả mã đã biên dịch và các tệp được nhúng / tải trước. nên là một
gấp ba,

, ,

trong đó native_encoder là một tệp thực thi gốc nén stdin thành stdout (
giao diện đơn giản nhất có thể), js_decoder là một tệp JavaScript triển khai một
decoder, và js_name là tên của hàm để gọi trong tệp giải mã (mà
nên nhận một mảng / mảng được định kiểu và trả về một mảng / mảng đã được định kiểu. Nén
chỉ hoạt động khi tạo HTML. Khi bật tính năng nén, tất cả các tệp được lưu trữ được chỉ định là
tải trước được nén trong một kho lưu trữ lớn, có cùng tên với
xuất HTML nhưng với hậu tố .data.compress

--giảm thiểu
0: Không giảm thiểu khoảng trắng JavaScript đã tạo (mặc định trong -O0, -O1, hoặc nếu
-g Được sử dụng)

1: Giảm thiểu JavaScript được tạo

khoảng trắng (mặc định trong -O2+, giả sử -g Không được sử dụng)

--tách ra
Tách tệp javascript kết quả thành nhiều phần để dễ gỡ lỗi. Tùy chọn này
chỉ hoạt động nếu Javascript được tạo (target -o .js). Tệp có chức năng
khai báo phải được tải trước tệp chính khi thực thi.

Không có tùy chọn "-g":

Tạo tệp có khai báo hàm có kích thước cho trước với hậu tố
"_functions.partxxx.js" và một tệp chính có hậu tố ".js".

Với tùy chọn "-g":

Tạo lại cấu trúc thư mục của tệp nguồn C và chức năng lưu trữ
khai báo trong các tệp C tương ứng của chúng với hậu tố ".js". Nếu một tập tin như vậy
vượt quá kích thước đã cho, các tệp có hậu tố ".partxxx.js" sẽ được tạo. Chính
tệp nằm trong thư mục cơ sở và có hậu tố ".js".

--trói buộc Biên dịch mã nguồn bằng cách sử dụng phương pháp liên kết "embind", kết nối C / C ++
và JS.

--ignore-động-liên kết Thông thường emcc sẽ coi liên kết động như
liên kết tĩnh, bằng cách liên kết trong mã từ thư viện động. Điều này không thành công nếu
cùng một thư viện động được liên kết nhiều lần. Với tùy chọn này, liên kết động
bị bỏ qua, điều này cho phép hệ thống xây dựng tiếp tục mà không có lỗi. Tuy nhiên bạn
sẽ cần tự liên kết thủ công với các thư viện được chia sẻ sau này.

--shell-file
Tên đường dẫn đến tệp HTML khung được sử dụng khi tạo đầu ra HTML. Cái vỏ
tệp được sử dụng cần có mã thông báo này bên trong: {{{SCRIPT_CODE}}} Lưu ý rằng điều này
đối số bị bỏ qua nếu mục tiêu không phải HTML được chỉ định bằng cách sử dụng -o tùy chọn.

--js-thư viện
Một thư viện JavaScript để sử dụng ngoài những thư viện trong src / library_ * của Emscripten

-v Bật đầu ra dài dòng. Điều này sẽ vượt qua -v để Clang và cũng bật EMCC_DEBUG để
chi tiết hoạt động của emcc

--jcache
Sử dụng bộ nhớ cache JavaScript. Điều này được tắt theo mặc định. Khi được bật, emcc sẽ lưu trữ
kết quả của quá trình biên dịch trong bộ đệm ẩn và kiểm tra bộ đệm khi biên dịch sau,
một cái gì đó giống như những gì ccache làm. Điều này cho phép các bản dựng tăng dần - bạn đang ở đâu
biên dịch một chương trình lớn nhưng chỉ sửa đổi một phần nhỏ của nó - để nhanh hơn nhiều
(với chi phí của nhiều IO đĩa hơn để truy cập bộ nhớ cache). Lưu ý rằng bạn cần bật
--jcache để tải và lưu dữ liệu, vì vậy bạn phải bật nó trên một bản dựng đầy đủ
để tăng tốc bản dựng tăng dần sau này (nơi bạn cũng kích hoạt nó).

Bộ nhớ đệm hoạt động riêng biệt trên 4 phần của quá trình biên dịch: 'pre' là các loại và toàn cục
biến; thông tin đó sau đó được đưa vào 'funcs' là các chức năng (
chúng tôi song song hóa), và sau đó 'đăng' bổ sung thông tin cuối cùng dựa trên
các chức năng (ví dụ: chúng ta có cần mã hỗ trợ long64 không). Cuối cùng, 'jsfuncs' là
Tối ưu hóa cấp JavaScript. Mỗi phần trong số 4 phần có thể được lưu trữ riêng biệt, nhưng
lưu ý rằng chúng có thể ảnh hưởng lẫn nhau: Nếu bạn biên dịch lại một tệp C ++ duy nhất
thay đổi một biến toàn cục - ví dụ: thêm, xóa hoặc sửa đổi một biến toàn cục, chẳng hạn
bằng cách thêm printf hoặc bằng cách thêm dấu thời gian biên dịch, thì 'pre' không thể là
được tải từ bộ nhớ cache. Và vì đầu ra của 'pre được gửi đến' funcs 'và' post ', chúng
cũng sẽ bị vô hiệu và chỉ 'jsfuncs' mới được lưu vào bộ nhớ đệm. Vì vậy, tránh sửa đổi
hình cầu để cho phép bộ nhớ đệm hoạt động đầy đủ.

Để giải quyết vấn đề được đề cập trong đoạn trước, bạn có thể sử dụng

emscripten_jcache_printf

khi thêm các printfs gỡ lỗi vào mã của bạn. Chức năng đó được xử lý trước đặc biệt để
rằng nó không tạo một chuỗi toàn cầu không đổi cho đối số đầu tiên của nó. Nhìn thấy
emscripten.h để biết thêm chi tiết. Đặc biệt lưu ý rằng bạn cần phải có
gọi hàm đó trong mã của bạn * trước khi * bạn thêm một hàm và thực hiện
xây dựng, để thêm một tham chiếu bên ngoài (cũng là một thuộc tính toàn cục) không
làm mất hiệu lực mọi thứ.

Lưu ý rằng bạn nên sử dụng -g trong giai đoạn liên kết (bitcode tới JS), để jcache
hoạt động (nếu không, quá trình rút gọn JS có thể gây nhầm lẫn cho nó).

--xóa bộ đệm
Xóa bộ đệm ẩn của các thư viện hệ thống emscripten đã biên dịch theo cách thủ công (libc ++,
libc ++ abi, libc). Điều này thường được xử lý tự động, nhưng nếu bạn cập nhật llvm
tại chỗ (thay vì có một thư mục khác cho phiên bản mới), bộ nhớ đệm
cơ chế có thể bị nhầm lẫn. Xóa bộ nhớ cache có thể khắc phục các sự cố kỳ lạ liên quan đến
sự không tương thích trong bộ nhớ cache, chẳng hạn như tiếng kêu không liên kết được với các tệp thư viện. Điều này cũng
xóa dữ liệu được lưu trong bộ nhớ cache khác như jcache và bộ mở lại bootstrapped. Sau
bộ nhớ cache bị xóa, quá trình này sẽ thoát.

--save-bc PATH
Khi biên dịch sang JavaScript hoặc HTML, tùy chọn này sẽ lưu một bản sao của mã bit
đến đường dẫn được chỉ định. Mã bit sẽ bao gồm tất cả các tệp được liên kết, bao gồm
thư viện tiêu chuẩn và sau bất kỳ tối ưu hóa thời gian liên kết nào (nếu có).

--bộ nhớ-init-file
Nếu bật, chúng tôi tạo một tệp khởi tạo bộ nhớ riêng biệt. Điều này hiệu quả hơn
hơn là lưu trữ dữ liệu khởi tạo bộ nhớ được nhúng bên trong JavaScript dưới dạng văn bản.
(mặc định là tắt)

Tệp đích, nếu được chỉ định (-o ), xác định những gì sẽ được tạo:

.js
JavaScript

.html
HTML có nhúng JavaScript

.bc
Mã bit LLVM (mặc định)

.o
Mã bit LLVM (giống như .bc)

(Lưu ý rằng nếu --bộ nhớ-init-file được sử dụng, sau đó bổ sung vào tệp .js hoặc .html
được tạo, tệp .mem cũng sẽ xuất hiện.)

Sản phẩm -c tùy chọn (thông báo cho gcc không chạy trình liên kết) sẽ làm cho mã bit LLVM
được tạo, vì emcc chỉ tạo JavaScript trong giai đoạn xây dựng liên kết cuối cùng.

(Các) tệp đầu vào có thể là tệp mã nguồn mà Clang có thể xử lý (C hoặc C ++), LLVM
mã bit ở dạng nhị phân hoặc các tệp lắp ráp LLVM ở dạng con người có thể đọc được.

emcc bị ảnh hưởng bởi một số biến môi trường. Để biết chi tiết, hãy xem nguồn của emcc
(tìm kiếm 'os.environ').

emcc: các mục tiêu được hỗ trợ: bitcode llvm, javascript, KHÔNG phải elf (autoconf thích xem elf
ở trên để bật hỗ trợ đối tượng được chia sẻ)

BẢN QUYỀN

Bản quyền © 2013 các tác giả Emscripten (xem AUTHORS.txt) Đây là mã nguồn mở và miễn phí
phần mềm theo giấy phép MIT. KHÔNG có bảo hành; thậm chí không đối với KHẢ NĂNG LẬP TỨC hoặc
PHÙ HỢP CHO MỤC ĐÍCH CỤ THỂ.

Sử dụng emcc trực tuyến bằng các dịch vụ onworks.net