emcc - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

emcc - ส่วนหน้าคอมไพเลอร์ Emscripten

DESCRIPTION

emcc [ตัวเลือก] ไฟล์...

ส่วนมาก ปกติ gcc/g++ ตัวเลือก จะ งาน, for ตัวอย่าง:
--ช่วยด้วย แสดงข้อมูลนี้

--รุ่น
แสดงข้อมูลเวอร์ชันคอมไพเลอร์

Options ที่ เป็น การแก้ไข or ใหม่ in อีเอ็มซี รวมถึง:
-O0 ไม่มีการเพิ่มประสิทธิภาพ (ค่าเริ่มต้น)

-O1 การเพิ่มประสิทธิภาพอย่างง่าย รวมถึง asm.js, LLVM -O1 การเพิ่มประสิทธิภาพและไม่มีรันไทม์
การยืนยันหรือการจับข้อยกเว้น C ++ (เพื่อเปิดใช้งานการจับข้อยกเว้น C ++ อีกครั้ง ใช้ -s
DISABLE_EXCEPTION_CATCHING=0 ) (สำหรับรายละเอียดเกี่ยวกับผลกระทบของ opt . ต่างๆ
ระดับ โปรดดูที่ apply_opt_level() ใน tools/shared.py และ src/settings.js ด้วย) หมายเหตุ:
การเพิ่มประสิทธิภาพทำได้เฉพาะเมื่อคอมไพล์เป็น JavaScript ไม่ใช่ระดับกลาง
บิตโค้ด *เว้นแต่* คุณสร้างด้วย EMCC_OPTIMIZE_NORMALY=1 (ไม่แนะนำเว้นแต่
รู้ว่ากำลังทำอะไรอยู่!)

-O2 As -O1, บวกกับ relooper (การพักผ่อนหย่อนใจแบบวนซ้ำ), LLVM -O2 การเพิ่มประสิทธิภาพและ

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2รวมถึงการเพิ่มประสิทธิภาพที่เป็นอันตรายที่อาจทำลายรหัสที่สร้างขึ้น! สิ่งนี้เสริม

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --ปิด 1
--llvm-lto 1

ไม่แนะนำเลย ทางที่ดีควรลองใช้แต่ละอย่างแยกกันบน
ด้านบนของ -O2 เพื่อดูว่าทำงานอย่างไร ดู wiki และ src/settings.js (สำหรับ -s ตัวเลือก)
สำหรับข้อมูลเพิ่มเติม

-s ตัวเลือก=ค่า
ตัวเลือกการสร้างโค้ด JavaScript ที่ส่งผ่านไปยังคอมไพเลอร์ emscripten สำหรับ
ตัวเลือกที่ใช้ได้ โปรดดูที่ src/settings.js โปรดทราบว่าสำหรับตัวเลือกที่เป็นรายการ คุณ
ต้องการเครื่องหมายคำพูดในเชลล์ส่วนใหญ่ ตัวอย่างเช่น

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

or

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

(หากไม่มี "s ภายนอกในสิ่งใดสิ่งหนึ่งคุณจะได้รับข้อผิดพลาด)

คุณยังสามารถระบุไฟล์ที่จะอ่านค่าได้ เช่น

-s DEAD_FUNCTIONS=@/เส้นทาง/ถึง/ไฟล์

เนื้อหาของ /พาธ/ถึง/ไฟล์ จะถูกอ่าน JSON.parsed และตั้งค่าเป็น DEAD_FUNCTIONS
(เพื่อให้ไฟล์สามารถมี

["_func1", "func2"]

). โปรดทราบว่าเส้นทางจะต้องเป็นแบบสัมบูรณ์ ไม่ใช่แบบสัมพัทธ์

-g ใช้ข้อมูลการดีบัก โปรดทราบว่าคุณต้องการสิ่งนี้ในระหว่างขั้นตอนการคอมไพล์ล่าสุดจาก
บิตโค้ดเป็น JavaScript มิฉะนั้นเราจะลบออกโดยค่าเริ่มต้นใน -O1 ขึ้นไป ใน
-O0, หมายเลขบรรทัดจะแสดงในรหัสที่สร้างขึ้น ใน -O1 ขึ้นไป
เครื่องมือเพิ่มประสิทธิภาพจะลบความคิดเห็นเหล่านั้น อย่างไรก็ตาม แฟล็กนี้มีผลกับ
ปิดการใช้งานสิ่งที่ทำให้ชื่อ mangling หรือย่อ (ปิดหรือ
ลงทะเบียนผ่าน)

--พิมพ์อาร์เรย์
0: ไม่มีอาร์เรย์ที่พิมพ์ 1: อาร์เรย์ที่พิมพ์แบบขนาน 2: อาร์เรย์ที่พิมพ์แบบ C ที่ใช้ร่วมกัน
(เริ่มต้น)

--llvm-ตัวเลือก
0: ไม่มีการเพิ่มประสิทธิภาพ LLVM (ค่าเริ่มต้นใน -O0) 1: -O1 การเพิ่มประสิทธิภาพ LLVM (ค่าเริ่มต้นใน
-O1) 2: -O2 การเพิ่มประสิทธิภาพ LLVM 3: -O3 การเพิ่มประสิทธิภาพ LLVM (ค่าเริ่มต้นใน -O2+)

--llvm-lto
0: ไม่มี LLVM LTO (ค่าเริ่มต้นเป็น -O2 และต่ำกว่า) 1: LLVM LTO (ค่าเริ่มต้นเป็น -O3) หมายเหตุ: ถ้า
ไม่มีการเรียกใช้การปรับให้เหมาะสม LLVM (ดู --llvm-ตัวเลือก) การตั้งค่านี้เป็น 1 จะไม่มีผลใดๆ

--ปิด
0: ไม่มีคอมไพเลอร์ปิด (ค่าเริ่มต้นเป็น -O2 และด้านล่าง) 1: เรียกใช้คอมไพเลอร์ปิด นี้
ลดขนาดโค้ดลงอย่างมาก และในบางกรณีอาจเพิ่มความเร็วรันไทม์ (แม้ว่า
ตรงกันข้ามอาจเกิดขึ้นได้) โปรดทราบว่าต้องใช้เวลาในการทำงาน และอาจต้องใช้บ้าง
การเปลี่ยนแปลงรหัส สิ่งนี้ถูกเรียกใช้โดยค่าเริ่มต้นใน -O3.

ในโหมด asm.js การปิดจะใช้กับโค้ด 'shell' รอบๆ คอมไพล์ . เท่านั้น
รหัส (โค้ดที่คอมไพล์แล้วจะถูกประมวลผลโดยตัวย่อ asm.js แบบกำหนดเอง)

หมายเหตุ: หากคอมไพเลอร์ปิดมีหน่วยความจำไม่เพียงพอ ให้ลองปรับ JAVA_HEAP_SIZE ใน
สภาพแวดล้อม (เช่น ถึง 4096m สำหรับ 4GB)

--js-แปลง
จะถูกเรียกบนรหัสที่สร้างขึ้นก่อนที่จะได้รับการปรับให้เหมาะสม สิ่งนี้ช่วยให้คุณ
แก้ไขจาวาสคริปต์ เช่น เพิ่มโค้ดบางส่วนหรือลบโค้ดบางส่วน ในทางใดทางหนึ่ง
ว่าการปรับเปลี่ยนเหล่านั้นจะได้รับการปรับให้เหมาะสมพร้อมกับรหัสที่สร้างขึ้น
อย่างถูกต้อง. จะถูกเรียกด้วยชื่อไฟล์ของรหัสที่สร้างเป็น a
พารามิเตอร์; ในการแก้ไขโค้ด คุณสามารถอ่านข้อมูลเดิมแล้วผนวกเข้ากับมัน
หรือเขียนทับด้วยข้อมูลที่แก้ไข ถูกตีความว่าเป็นช่องว่างที่แยกจากกัน
รายการอาร์กิวเมนต์ เช่น ของ "python processor.py" จะทำให้ python
สคริปต์ที่จะเรียกใช้

--pre-js
ไฟล์ที่มีการเพิ่มเนื้อหาก่อนโค้ดที่สร้าง เสร็จแล้ว *ก่อน*
การปรับให้เหมาะสม ดังนั้นมันจะถูกย่อให้เล็กสุดอย่างเหมาะสมหากคอมไพเลอร์ปิดทำงาน

--post-js
ไฟล์ที่มีการเพิ่มเนื้อหาหลังจากโค้ดที่สร้าง สิ่งนี้เสร็จสิ้น *ก่อน*
การปรับให้เหมาะสม ดังนั้นมันจะถูกย่อให้เล็กสุดอย่างเหมาะสมหากคอมไพเลอร์ปิดทำงาน

--ฝังไฟล์
ไฟล์ที่จะฝังภายใน JavaScript ที่สร้างขึ้น โค้ดที่คอมไพล์แล้วจะสามารถ
เข้าถึงไฟล์ในไดเร็กทอรีปัจจุบันด้วยชื่อเดียวกับที่ให้ไว้ที่นี่ ดังนั้นถ้า
คุณทำ --ฝังไฟล์ dir/file.dat จากนั้น (1) dir/file.dat ต้องมีสัมพันธ์กับ
โดยที่คุณเรียกใช้ emcc และ (2) โค้ดที่คอมไพล์ของคุณจะสามารถค้นหาไฟล์ได้โดย
กำลังอ่านเส้นทางเดียวกันนั้น dir/file.dat หากไดเร็กทอรีถูกส่งผ่านมาที่นี่ ไดเร็กทอรีทั้งหมดจะเป็น
เนื้อหาจะถูกฝัง

--preload-ไฟล์
ไฟล์ที่จะโหลดล่วงหน้าก่อนที่จะรันโค้ดที่คอมไพล์แบบอะซิงโครนัส มิฉะนั้น
คล้ายกับ --ฝังไฟล์ยกเว้นว่าตัวเลือกนี้มีความเกี่ยวข้องเฉพาะเมื่อสร้าง
HTML (ใช้ XHR ไบนารีแบบอะซิงโครนัส) หรือ JS ที่จะใช้ในหน้าเว็บ ถ้า
ไดเร็กทอรีถูกส่งมาที่นี่ เนื้อหาทั้งหมดจะถูกโหลดไว้ล่วงหน้า ไฟล์ที่โหลดไว้ล่วงหน้า
ถูกเก็บไว้ใน filename.data โดยที่ filename.html เป็นไฟล์หลักที่คุณกำลังรวบรวม
ถึง. ในการรันโค้ดของคุณ คุณจะต้องมีทั้ง .html และ .data

emcc รัน tools/file_packager.py เพื่อทำแพ็คเกจจริงของ Embedded and
ไฟล์ที่โหลดไว้ล่วงหน้า คุณสามารถเรียกใช้ file packager ได้ด้วยตัวเองหากต้องการ โปรดดูที่ docs
ภายในไฟล์นั้น จากนั้นคุณควรใส่เอาต์พุตของตัวทำแพ็กเกจไฟล์ใน emcc
--pre-jsเพื่อให้ทำงานก่อนโค้ดที่คอมไพล์หลักของคุณ (หรือรันก่อน in
อย่างอื่น)

--การบีบอัด
บีบอัดทั้งโค้ดที่คอมไพล์แล้วและไฟล์ฝังตัว/ไฟล์ที่โหลดไว้ล่วงหน้า ควรจะเป็น
สาม,

, ,

โดยที่ native_encoder เป็นไฟล์เรียกทำงานแบบเนทีฟที่บีบอัด stdin เป็น stdout (the
อินเทอร์เฟซที่ง่ายที่สุด) js_decoder เป็นไฟล์ JavaScript ที่ใช้a
ตัวถอดรหัส และ js_name เป็นชื่อของฟังก์ชันที่จะเรียกใช้ในไฟล์ตัวถอดรหัส (ซึ่ง
ควรได้รับอาร์เรย์ / อาร์เรย์ที่พิมพ์แล้วและส่งคืนอาร์เรย์ / อาร์เรย์ที่พิมพ์ การบีบอัด
ใช้งานได้เฉพาะเมื่อสร้าง HTML เมื่อเปิดการบีบอัดไฟล์ทั้งหมดที่ระบุเป็น
ที่โหลดไว้ล่วงหน้าจะถูกบีบอัดในไฟล์เก็บถาวรขนาดใหญ่หนึ่งไฟล์ซึ่งมีชื่อเดียวกับ
เอาต์พุต HTML แต่มีส่วนต่อท้าย .data.compress

--ลดขนาด
0: อย่าย่อช่องว่างของ JavaScript ที่สร้างขึ้น (ค่าเริ่มต้นเป็น -O0, -O1, หรือถ้า
-g ถูกนำมาใช้)

1: ลดขนาด JavaScript's . ที่สร้างขึ้น

ช่องว่าง (ค่าเริ่มต้นใน -O2+, สมมติว่า -g ไม่ได้ใช้)

--แยก
แบ่งไฟล์จาวาสคริปต์ที่เป็นผลลัพธ์ออกเป็นชิ้น ๆ เพื่อให้ง่ายต่อการดีบัก ตัวเลือกนี้
ใช้งานได้ก็ต่อเมื่อ Javascript ถูกสร้างขึ้น (target -o .js) ไฟล์ที่มีฟังก์ชั่น
ต้องโหลดการประกาศก่อนไฟล์หลักเมื่อดำเนินการ

ไม่มีตัวเลือก "-g":

สร้างไฟล์ที่มีการประกาศฟังก์ชันถึงขนาดที่กำหนดด้วยคำต่อท้าย
"_functions.partxxx.js" และไฟล์หลักที่มีส่วนต่อท้าย ".js"

ด้วยตัวเลือก "-g":

สร้างโครงสร้างไดเร็กทอรีของไฟล์ต้นฉบับ C และจัดเก็บฟังก์ชัน
การประกาศในไฟล์ C ที่เกี่ยวข้องด้วยคำต่อท้าย ".js" หากเป็นไฟล์ดังกล่าว
เกินขนาดที่กำหนด ไฟล์ที่มีส่วนต่อท้าย ".partxxx.js" จะถูกสร้างขึ้น หลัก
ไฟล์อยู่ในไดเร็กทอรีฐานและมีส่วนต่อท้าย ".js"

--ผูก รวบรวมซอร์สโค้ดโดยใช้วิธีการผูก "embind" ซึ่งเชื่อมต่อ C/C++
และจส.

--ignore-ไดนามิกการเชื่อมโยง โดยปกติ emcc จะถือว่าการเชื่อมโยงแบบไดนามิกเช่น
การเชื่อมโยงแบบคงที่โดยการเชื่อมโยงในโค้ดจากไลบรารีแบบไดนามิก สิ่งนี้ล้มเหลวหาก
ไลบรารีไดนามิกเดียวกันมีการเชื่อมโยงมากกว่าหนึ่งครั้ง ด้วยตัวเลือกนี้ การเชื่อมโยงแบบไดนามิก
จะถูกละเว้น ซึ่งช่วยให้ระบบบิลด์ดำเนินการต่อไปโดยไม่มีข้อผิดพลาด อย่างไรก็ตาม คุณ
จะต้องเชื่อมโยงด้วยตนเองไปยังไลบรารีที่แชร์ในภายหลังด้วยตัวคุณเอง

--shell-ไฟล์
ชื่อพาธไปยังไฟล์ HTML โครงกระดูกที่ใช้เมื่อสร้างเอาต์พุต HTML เปลือก
ไฟล์ที่ใช้ต้องมีโทเค็นนี้อยู่ภายใน: {{{ SCRIPT_CODE }}} โปรดทราบว่า this
อาร์กิวเมนต์จะถูกละเว้นหากมีการระบุเป้าหมายอื่นที่ไม่ใช่ HTML โดยใช้ -o ตัวเลือก

--js-ห้องสมุด
ไลบรารี JavaScript ที่จะใช้นอกเหนือจากที่อยู่ใน src/library_* ของ Emscripten

-v เปิดเอาต์พุตแบบละเอียด มันจะผ่านไป -v ไปที่ Clang และยังเปิดใช้งาน EMCC_DEBUG to
รายละเอียดการดำเนินงานของ emcc

--jcache
ใช้แคช JavaScript สิ่งนี้ถูกปิดใช้งานโดยค่าเริ่มต้น เมื่อเปิดใช้งาน emcc จะจัดเก็บ
ผลลัพธ์ของการคอมไพล์ในแคชและตรวจสอบแคชเมื่อทำการคอมไพล์ในภายหลัง
สิ่งที่เหมือนสิ่งที่ ccache ทำ ซึ่งช่วยให้สร้างส่วนเพิ่มได้ - คุณอยู่ที่ไหน
รวบรวมโปรแกรมขนาดใหญ่แต่แก้ไขเพียงส่วนเล็ก ๆ ของมัน - ให้เร็วขึ้นมาก
(ด้วยค่าใช้จ่ายของดิสก์ IO เพิ่มเติมสำหรับการเข้าถึงแคช) โปรดทราบว่าคุณต้องเปิดใช้งาน
--jcache สำหรับทั้งการโหลดและการบันทึกข้อมูล ดังนั้นคุณต้องเปิดใช้งานบนบิลด์แบบเต็ม
สำหรับบิลด์ที่เพิ่มขึ้นในภายหลัง (ที่คุณเปิดใช้งานด้วย) เพื่อให้เร็วขึ้น

การแคชทำงานแยกกันในการรวบรวม 4 ส่วน: 'pre' ซึ่งเป็นประเภทและส่วนกลาง
ตัวแปร; ข้อมูลนั้นจะถูกป้อนเข้าสู่ 'funcs' ซึ่งเป็นฟังก์ชัน (ซึ่ง
เราขนานกัน) จากนั้น 'โพสต์' ซึ่งเพิ่มข้อมูลสุดท้ายตาม
ฟังก์ชั่น (เช่น เราต้องการรหัสสนับสนุน long64) ในที่สุด 'jsfuncs' คือ
การเพิ่มประสิทธิภาพระดับ JavaScript แต่ละ 4 ส่วนสามารถแคชแยกกันได้ แต่
โปรดทราบว่าพวกเขาสามารถส่งผลกระทบต่อกันและกัน: หากคุณคอมไพล์ไฟล์ C ++ ไฟล์เดียวที่
เปลี่ยนตัวแปรส่วนกลาง - เช่น เพิ่ม ลบ หรือแก้ไขตัวแปรส่วนกลาง พูด
โดยการเพิ่ม printf หรือโดยการเพิ่มเวลาคอมไพล์แล้ว 'pre' จะไม่สามารถ
โหลดจากแคช และเนื่องจากเอาต์พุต 'pre's ถูกส่งไปยัง 'funcs' และ 'post' พวกเขา
ก็จะใช้งานไม่ได้เช่นกัน และจะแคชเฉพาะ 'jsfuncs' เพื่อหลีกเลี่ยงการปรับเปลี่ยน
globals เพื่อให้การแคชทำงานอย่างเต็มที่

เพื่อแก้ไขปัญหาที่กล่าวถึงในย่อหน้าก่อนหน้า คุณสามารถใช้

emscripten_jcache_printf

เมื่อเพิ่มการดีบัก printfs ให้กับโค้ดของคุณ ฟังก์ชั่นนั้นถูกประมวลผลล่วงหน้าเป็นพิเศษดังนั้น
ว่าจะไม่สร้างสตริงคงที่โกลบอลสำหรับอาร์กิวเมนต์แรก ดู
emscripten.h สำหรับรายละเอียดเพิ่มเติม โดยเฉพาะอย่างยิ่งคุณต้องมี
เรียกใช้ฟังก์ชันนั้นในโค้ดของคุณ *ก่อน* คุณเพิ่มฟังก์ชันนั้นและทำ incremental
บิลด์ ดังนั้นการเพิ่มการอ้างอิงภายนอก (รวมถึงคุณสมบัติโกลบอลด้วย) ไม่ได้
ทำให้ทุกอย่างเป็นโมฆะ

โปรดทราบว่าคุณควรใช้ -g ระหว่างขั้นตอนการเชื่อมโยง (บิตโค้ดกับ JS) สำหรับ jcache ถึง
งาน (ไม่เช่นนั้น JS minification อาจทำให้สับสนได้)

--ล้างแคช
ล้างแคชของไลบรารีระบบ emscripten ที่คอมไพล์ด้วยตนเอง (libc++,
libc++abi, libc) โดยปกติจะได้รับการจัดการโดยอัตโนมัติ แต่ถ้าคุณอัปเดต llvm
แทนที่ (แทนที่จะมีไดเร็กทอรีอื่นสำหรับเวอร์ชันใหม่) แคช
กลไกอาจสับสนได้ การล้างแคชสามารถแก้ไขปัญหาแปลก ๆ ที่เกี่ยวข้องกับ
ความไม่เข้ากันของแคช เช่น clang ไม่สามารถเชื่อมโยงกับไฟล์ไลบรารี นี้ด้วย
ล้างข้อมูลแคชอื่น ๆ เช่น jcache และ boottrapped relooper หลังจาก
แคชถูกล้าง กระบวนการนี้จะออก

--บันทึก-BC เส้นทาง
เมื่อคอมไพล์เป็น JavaScript หรือ HTML ตัวเลือกนี้จะบันทึกสำเนาของบิตโค้ด
ไปยังเส้นทางที่กำหนด บิตโค้ดจะรวมไฟล์ทั้งหมดที่ถูกเชื่อมโยง รวมทั้ง
ไลบรารีมาตรฐาน และหลังจากการเพิ่มประสิทธิภาพเวลาลิงก์ (ถ้ามี)

--memory-init-ไฟล์
หากเปิดอยู่ เราจะสร้างไฟล์เริ่มต้นหน่วยความจำแยกต่างหาก นี้มีประสิทธิภาพมากขึ้น
มากกว่าการจัดเก็บข้อมูลการเริ่มต้นหน่วยความจำที่ฝังอยู่ภายใน JavaScript เป็นข้อความ
(ค่าเริ่มต้นคือปิด)

ไฟล์เป้าหมาย หากระบุ (-o ) กำหนดสิ่งที่จะถูกสร้างขึ้น:

.js
JavaScript

.html
HTML พร้อม JavaScript ที่ฝังตัว

.bc
บิตโค้ด LLVM (ค่าเริ่มต้น)

.o
บิตโค้ด LLVM (เหมือนกับ .bc)

(โปรดทราบว่าถ้า --memory-init-ไฟล์ ถูกใช้ นอกเหนือจากไฟล์ .js หรือ .html ที่เป็น
ที่สร้างขึ้น ไฟล์ .mem จะปรากฏขึ้นด้วย)

พื้นที่ -c ตัวเลือก (ซึ่งบอก gcc ไม่ให้เรียกใช้ตัวเชื่อมโยง) จะทำให้บิตโค้ด LLVM เป็น
สร้างขึ้น เนื่องจาก emcc สร้างเฉพาะ JavaScript ในขั้นตอนการเชื่อมโยงขั้นสุดท้ายของการสร้างเท่านั้น

ไฟล์อินพุตสามารถเป็นไฟล์ซอร์สโค้ดที่ Clang สามารถจัดการได้ (C หรือ C ++), LLVM
บิตโค้ดในรูปแบบไบนารีหรือไฟล์แอสเซมบลี LLVM ในรูปแบบที่มนุษย์อ่านได้

emcc ได้รับผลกระทบจากตัวแปรสภาพแวดล้อมหลายอย่าง ดูรายละเอียดที่มาของemcc
(ค้นหา 'os.environ')

emcc: เป้าหมายที่รองรับ: llvm bitcode, javascript, ไม่ใช่ elf (autoconf ชอบเห็นเอลฟ์
ด้านบนเพื่อเปิดใช้งานการสนับสนุนวัตถุที่ใช้ร่วมกัน)

ลิขสิทธิ์

ลิขสิทธิ์ © 2013 ผู้เขียน Emscripten (ดู AUTHORS.txt) นี่เป็นโอเพ่นซอร์สฟรีและ
ซอฟต์แวร์ภายใต้ใบอนุญาต MIT ไม่มีการรับประกัน ไม่ใช่เพื่อการค้าหรือ
ความเหมาะสมสำหรับวัตถุประสงค์เฉพาะ

ใช้ emcc ออนไลน์โดยใช้บริการ onworks.net