ล่ามสร้างรหัสเครื่องหรือไม่

ฉันศึกษาหัวข้อคอมไพเลอร์และล่ามอย่างเข้มข้น ฉันต้องการตรวจสอบว่าความเข้าใจพื้นฐานของฉันถูกต้องหรือไม่ดังนั้นให้ลองทำดังนี้:

ฉันมีภาษาที่เรียกว่า "Foobish" และคำหลักคือ

<OUTPUT> 'TEXT', <Number_of_Repeats>;

ดังนั้นถ้าฉันต้องการพิมพ์ไปยังคอนโซล 10 ครั้งฉันจะเขียน

OUTPUT 'Hello World', 10;

สวัสดี World.foobish- ไฟล์

ตอนนี้ฉันเขียนล่ามในภาษาที่ฉันเลือก - C # ในกรณีนี้:

using System;

namespace FoobishInterpreter
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            analyseAndTokenize(Hello World.foobish-file)//Pseudocode
            int repeats = Token[1];
            string outputString = Token[0];
            for (var i = 0; i < repeats; i++)
            {
                Console.WriteLine(outputString);
            }
        }
    }
}

ในระดับล่ามที่ง่ายมากล่ามจะวิเคราะห์ไฟล์สคริปต์และอื่น ๆ และดำเนินการเกี่ยวกับภาษาที่เป็นอันตรายในลักษณะของการใช้งานล่าม

คอมไพเลอร์จะสร้างภาษาเครื่องที่ทำงานบนฮาร์ดแวร์จริงหรือไม่?

ดังนั้นล่ามจึงไม่สร้างภาษาเครื่อง แต่คอมไพเลอร์ทำเพื่อการป้อนข้อมูลหรือไม่

ฉันมีความเข้าใจผิดใด ๆ ในวิธีการพื้นฐานที่คอมไพเลอร์และล่ามทำงานอย่างไร

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

แต่วันนี้มีหลายรูปแบบในการใช้ "คอมไพเลอร์" และ "ล่าม" ตัวอย่างเช่น VB6 "คอมไพล์" เป็นรหัสไบต์ (รูปแบบของภาษาระดับกลาง ) ซึ่งจากนั้น "ตีความ" โดย VB Runtime กระบวนการที่คล้ายกันเกิดขึ้นใน C # ซึ่งสร้างCILซึ่งดำเนินการแล้วโดยJust-In-Time Compiler (JIT)ซึ่งในสมัยก่อนจะมีความคิดว่าเป็นล่าม คุณสามารถ "freeze-dry" เอาต์พุตของ JIT ลงในไบนารีที่ปฏิบัติการจริงได้โดยใช้NGen.exeซึ่งเป็นผลิตภัณฑ์ที่เป็นผลมาจากคอมไพเลอร์ในสมัยก่อน

ดังนั้นคำตอบสำหรับคำถามของคุณไม่ตรงไปตรงมาเหมือนครั้งก่อน

การอ่านเพิ่มเติม
Compilers vs. Interpreters บน Wikipedia

บทสรุปที่ฉันให้ไว้ด้านล่างใช้ "คอมไพเลอร์หลักการเทคนิคและเครื่องมือ", Aho, Lam, Sethi, Ullman, (Pearson International Edition, 2007), หน้า 1, 2 ด้วยการเพิ่มแนวคิดบางอย่างของฉันเอง

ทั้งสองกลไกพื้นฐานสำหรับการประมวลผลโปรแกรมที่มีการรวบรวมและการตีความ

การคอมไพล์ใช้เป็นอินพุตโปรแกรมต้นฉบับในภาษาที่กำหนดและส่งเอาต์พุตโปรแกรมเป้าหมายในภาษาเป้าหมาย

source program --> | compiler | --> target program

หากภาษาเป้าหมายเป็นรหัสเครื่องสามารถเรียกใช้งานได้กับโปรเซสเซอร์บางตัวโดยตรง:

input --> | target program | --> output

การรวบรวมเกี่ยวข้องกับการสแกนและแปลโปรแกรมอินพุตทั้งหมด (หรือโมดูล) และไม่เกี่ยวข้องกับการดำเนินการ

การตีความใช้เป็นอินพุตโปรแกรมต้นทางและอินพุตและสร้างเอาต์พุตของโปรแกรมต้นฉบับ

source program, input --> | interpreter | --> output

การตีความมักเกี่ยวข้องกับการประมวลผล (การวิเคราะห์และการดำเนินการ) โปรแกรมหนึ่งคำสั่งพร้อมกัน

ในทางปฏิบัติตัวประมวลผลภาษาจำนวนมากใช้การผสมผสานของสองวิธี เช่นโปรแกรม Java ถูกแปลเป็นครั้งแรก (เรียบเรียง) เป็นโปรแกรมระดับกลาง (รหัสไบต์):

source program --> | translator | --> intermediate program

ผลลัพธ์ของขั้นตอนนี้จะถูกดำเนินการ (ตีความ) โดยเครื่องเสมือน:

intermediate program + input --> | virtual machine | --> output

เพื่อทำให้สิ่งต่าง ๆ ซับซ้อนยิ่งขึ้น JVM สามารถทำการคอมไพล์แบบทันเวลาที่รันไทม์เพื่อแปลงรหัสไบต์เป็นรูปแบบอื่นซึ่งจะถูกเรียกใช้งาน

นอกจากนี้แม้ว่าคุณจะคอมไพล์เป็นภาษาเครื่องก็ยังมีล่ามที่ใช้งานไฟล์ไบนารี่ซึ่งประมวลผลโดยโปรเซสเซอร์พื้นฐาน ดังนั้นแม้ในกรณีนี้คุณกำลังใช้ไฮบริดของการรวบรวม + การตีความ

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

อย่างไรก็ตามการรวบรวมและตีความเป็นกระบวนการที่แตกต่างกันสองประเภทดังที่อธิบายไว้ในแผนภาพด้านบน

เพื่อตอบคำถามเบื้องต้น

คอมไพเลอร์จะสร้างภาษาเครื่องที่ทำงานบนฮาร์ดแวร์ทางกายภาพโดยตรง

คอมไพเลอร์แปลโปรแกรมที่เขียนขึ้นสำหรับเครื่อง M1 ไปเป็นโปรแกรมเทียบเท่าที่เขียนขึ้นสำหรับเครื่อง M2 เครื่องเป้าหมายสามารถใช้งานได้ในฮาร์ดแวร์หรือเป็นเครื่องเสมือน แนวคิดไม่มีความแตกต่าง จุดสำคัญคือคอมไพเลอร์จะดูรหัสและแปลเป็นภาษาอื่นโดยไม่ต้องดำเนินการ

ดังนั้นล่ามจึงไม่สร้างภาษาเครื่อง แต่คอมไพเลอร์ใช้สำหรับการป้อนข้อมูลหรือไม่

หากการสร้างคุณอ้างถึงเอาต์พุตแล้วคอมไพเลอร์จะสร้างโปรแกรมเป้าหมายซึ่งอาจเป็นภาษาเครื่องแปลภาษาไม่ได้

คอมไพเลอร์จะสร้างภาษาเครื่อง

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

คอมไพเลอร์สามารถรวบรวมจากภาษาระดับสูงเป็นภาษาระดับสูง (เช่น GWT ซึ่งรวบรวม Java เป็น ECMAScript) จากภาษาระดับสูงเป็นภาษาระดับต่ำ (เช่น Gambit ซึ่งรวบรวม Scheme ถึง C) จากภาษาระดับสูงถึงรหัสเครื่อง (เช่น GCJ ซึ่งรวบรวม Java เป็นรหัสท้องถิ่น) จากภาษาระดับต่ำถึงภาษาระดับสูง (เช่น Clue ซึ่งรวบรวม C ถึง Java, Lua, Perl, ECMAScript และ Common เสียงกระเพื่อม) จากภาษาระดับต่ำถึงภาษาระดับต่ำ (เช่น Android SDK ซึ่งรวบรวม JVML bytecode ถึง Dalvik bytecode) จากภาษาระดับต่ำถึงรหัสเครื่อง (เช่นคอมไพเลอร์ C1X ซึ่งเป็นส่วนหนึ่งของ HotSpot ซึ่งรวบรวม JVML bytecode เป็นรหัสเครื่อง), รหัสเครื่องเป็นภาษาระดับสูง (เรียกว่า "decompiler" ใด ๆ เช่น Emscripten ซึ่งรวบรวมรหัสเครื่องจักร LLVM เป็น ECMAScript)รหัสเครื่องเป็นภาษาระดับต่ำ (เช่นคอมไพเลอร์ JIT ใน JPC ซึ่งรวบรวมรหัสเนทีฟ x86 เป็น JVML bytecode) และรหัสเนทีฟเป็นรหัสเนทีฟ (เช่นคอมไพเลอร์ JIT ใน PearPC ซึ่งรวบรวมรหัสเนทีฟ PowerPC เป็นรหัสเนทีฟ x86)

โปรดทราบด้วยว่า "รหัสเครื่อง" เป็นคำที่คลุมเครือจริงๆด้วยเหตุผลหลายประการ ตัวอย่างเช่นมี CPU ที่ใช้งานโค้ด JVM แบบดั้งเดิมและมีล่ามซอฟต์แวร์สำหรับรหัสเครื่อง x86 ดังนั้นอะไรที่ทำให้ "รหัสเครื่องดั้งเดิม" หนึ่งอัน แต่ไม่ใช่อีกรหัสหนึ่ง นอกจากนี้ทุกภาษาคือรหัสสำหรับเครื่องนามธรรมสำหรับภาษานั้น

มีชื่อเฉพาะมากมายสำหรับคอมไพเลอร์ที่ทำหน้าที่พิเศษ แม้ว่าชื่อเหล่านี้จะเป็นชื่อเฉพาะ แต่ทั้งหมดยังคงเป็นคอมไพเลอร์ แต่เป็นคอมไพเลอร์ชนิดพิเศษ:

• หากภาษาAถูกมองว่าอยู่ในระดับเดียวกับ abstraction เท่ากับภาษาBคอมไพเลอร์อาจถูกเรียกว่าtranspiler (เช่น Ruby-to-ECMAScript-transpiler หรือ ECMAScript2015-to-ECMAScript5-transpiler)
• หากการรับรู้ภาษาAอยู่ในระดับที่ต่ำกว่าระดับนามธรรมกว่าภาษาBคอมไพเลอร์อาจถูกเรียกว่าdecompiler (เช่น x86-machine-code-to-C-decompiler)
• ถ้า language A == language Bคอมไพเลอร์อาจถูกเรียกว่าoptimizer , obfuscatorหรือminifier (ขึ้นอยู่กับหน้าที่เฉพาะของคอมไพเลอร์)

ซึ่งทำงานบนฮาร์ดแวร์ทางกายภาพโดยตรง

ไม่จำเป็น. มันอาจจะทำงานในล่ามหรือใน VM มันอาจจะถูกรวบรวมเป็นภาษาอื่นเพิ่มเติม

ดังนั้นล่ามจึงไม่สร้างภาษาเครื่อง แต่คอมไพเลอร์ใช้สำหรับการป้อนข้อมูลหรือไม่

ล่ามไม่ได้ผลิตอะไรเลย มันเพิ่งรันโปรแกรม

คอมไพเลอร์สร้างบางอย่าง แต่ไม่จำเป็นต้องเป็นภาษาเครื่องมันอาจเป็นภาษาใดก็ได้ มันอาจเป็นภาษาเดียวกันกับภาษาที่ป้อน! ตัวอย่างเช่น Supercompilers, LLC มีคอมไพเลอร์ที่ใช้จาวาเป็นอินพุตและสร้างจาวาที่ได้รับการปรับให้เหมาะสม มีคอมไพล์เลอร์ ECMAScript จำนวนมากซึ่งใช้ ECMAScript เป็นอินพุตและสร้าง ECMAScript ที่ปรับขนาดให้เล็กที่สุดและ obfuscated เป็นเอาต์พุตของพวกเขา

คุณอาจสนใจ:

• ทำความเข้าใจกับความแตกต่าง: ล่ามแบบดั้งเดิมคอมไพเลอร์ JIT ล่าม JIT และคอมไพเลอร์ AOT
• คอมโพเนนต์ / เฟสของคอมไพเลอร์ JIT ใดแตกต่างจากคอมไพเลอร์ก่อนเวลา

ฉันคิดว่าคุณควรทิ้งความคิดของ "ผู้แปลและล่าม" อย่างสิ้นเชิงเพราะมันเป็นขั้วที่ผิดพลาด

• คอมไพเลอร์เป็นหม้อแปลง : มันแปลงโปรแกรมคอมพิวเตอร์ที่เขียนในภาษาต้นฉบับและผลเทียบเท่าในภาษาเป้าหมาย โดยปกติแล้วภาษามาเป็นระดับที่สูงกว่าที่ภาษาเป้าหมาย - และถ้าหากมันเป็นวิธีอื่น ๆ ที่เรามักจะเรียกชนิดของหม้อแปลงที่Decompiler
• ล่ามเป็นเครื่องมือดำเนินการ มันรันโปรแกรมคอมพิวเตอร์ที่เขียนในภาษาเดียวตามข้อกำหนดของภาษานั้น เราส่วนใหญ่ใช้คำสำหรับซอฟต์แวร์ (แต่ในทางใดก็ตามซีพียูแบบคลาสสิคสามารถดูได้เป็น "ล่าม" ที่ใช้ฮาร์ดแวร์สำหรับรหัสเครื่อง)

คำว่าส่วนรวมสำหรับการเขียนโปรแกรมภาษานามธรรมประโยชน์ในโลกแห่งความจริงคือการดำเนินการ

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

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

ตัวอย่างของแผนการใช้งานรวมถึง:

• AC คอมไพเลอร์ที่แปลงรหัสเครื่อง C เป็น x86 และ x86 CPU ที่ประมวลผลรหัสนั้น
• AC คอมไพเลอร์ที่แปลง C เป็น LLVM IR, คอมไพเลอร์แบ็กเอนด์ LLVM ที่แปลง LLVM IR เป็นรหัสเครื่อง x86 และซีพียู x86 ที่ประมวลผลรหัสนั้น
• AC คอมไพเลอร์ที่แปลง C เป็น LLVM IR และล่าม LLVM ที่ดำเนินการ LLVM IR
• คอมไพเลอร์ Java ที่แปลง Java เป็น JVM bytecode และ JRE พร้อมล่ามที่เรียกใช้งานโค้ดดังกล่าว
• คอมไพเลอร์ Java ที่แปลง Java เป็น JVM bytecode และ JRE พร้อมทั้งล่ามที่ดำเนินการบางส่วนของรหัสนั้นและคอมไพเลอร์ที่แปลงส่วนอื่น ๆ ของรหัสนั้นเป็นรหัสเครื่อง x86 และ x86 CPU ที่ประมวลผลรหัสนั้น
• คอมไพเลอร์ Java ที่แปลง Java เป็น JVM bytecode และ ARM CPU ที่เรียกใช้งานโค้ดดังกล่าว
• คอมไพเลอร์ AC # ที่แปลง C # เป็น CIL, CLR ที่มีคอมไพเลอร์ที่แปลง CIL เป็นรหัสเครื่อง x86 และ x86 CPU ที่ประมวลผลรหัสนั้น
• ล่ามทับทิมที่ดำเนินการทับทิม
• สภาพแวดล้อม Ruby ที่มีทั้งล่ามที่เรียกใช้ Ruby และคอมไพเลอร์ที่แปลง Ruby เป็นรหัสเครื่อง x86 และ x86 CPU ที่ประมวลผลรหัสนั้น

... และต่อไป

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

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

ล่ามจะทำในสิ่งที่โปรแกรมของคุณควรทำ

ด้วยคำจำกัดความเหล่านี้สถานที่ที่มันคลุมเครือเป็นกรณีที่ผู้แปล / ล่ามของคุณสามารถคิดว่าทำสิ่งต่าง ๆ ขึ้นอยู่กับว่าคุณดูอย่างไร ตัวอย่างเช่น Python ใช้รหัส Python ของคุณและรวบรวมเป็น Python bytecode ที่คอมไพล์แล้ว หาก Python bytecode นี้ทำงานผ่านล่าม Python bytecode ก็จะทำสิ่งที่โปรแกรมของคุณควรจะทำ ในสถานการณ์ส่วนใหญ่ แต่นักพัฒนาหลามคิดว่าทั้งสองขั้นตอนเหล่านั้นจะถูกดำเนินการในขั้นตอนขนาดใหญ่เพื่อให้พวกเขาเลือกที่จะคิดว่าCPythonล่ามเป็นตีความ sourcecode ของพวกเขาและความจริงที่ว่ามันก็รวบรวมไปพร้อมกันถือว่าเป็นรายละเอียดการดำเนินงาน . ด้วยวิธีนี้มันเป็นเรื่องของมุมมอง

ต่อไปนี้เป็นความคิดที่เข้าใจง่ายระหว่างคอมไพเลอร์และล่าม

พิจารณา 3 ภาษา: ภาษาโปรแกรม , P (เขียนโปรแกรม) ภาษาโดเมน D (สำหรับสิ่งที่เกิดขึ้นกับโปรแกรมที่กำลังทำงาน); และภาษาเป้าหมาย , T (บางภาษาที่สาม)

แนวคิด

• เรียบเรียงแปล P เพื่อ T เพื่อให้คุณสามารถประเมิน T (D); แต่ทว่า

• ล่ามประเมิน P (D) โดยตรง