موضوع مقاله: مفسر (رایانش) | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # مفسر (رایانش) | مقدمه: با وجود اینکه تفسیر کردن و ترجمه کردن،compile دو وسیلهٔ اصلی هستند که از طریق آن‌ها زبان‌های برنامه‌نویسی اجرا می‌شوند، دو مقولهٔ کاملاً مجزا نیستند. | ## بخش 1: مفسر (رایانش) | یکی از دلایل این است که اغلب سیستم‌های مفسر برخی از کارهای ترجمه را انجام می‌دهند. از آن کمک گرفته می‌شود تا کدهای آماده به اجرایی که توسط مترجم که قسمتی از سیستم مفسر است ساخته‌شده را اجرا کند. برنامه‌های نوشته شده با جاوا از قبل ترجمه شده و به عنوان کدهای مستقل از ماشین، ذخیره می‌شوند و بعد در زمان اجراrun-time توسط یک مفسر (ماشین مجازی) اجرا می‌شوند. لفظ‌های زبان مفسر و زبان مترجم صرفاً به این معنا هستند که اساس پیاده‌سازی یک زبان برنامه‌نویسی یک مفسر است یا یک مترجم؛ یک زبان سطح بالا زبانی است که مستقل از پیاده‌سازی مشخصی است. کارایی عیب اصلی مفسرها این است که برنامه‌ای که تفسیر می‌شود، نسبت به برنامه‌ای که ترجمه شود، دیرتر اجرا می‌شود. غالباً اجرای یک برنامه تحت یک مفسر نسبت به اجرای کد ترجمه شده وقت بیشتری نیاز دارد. امّا مدت زمان تفسیر یک برنامه از مجموع زمان لازم برای ترجمه کردن و اجرا کردن آن، کمتر است. تفسیر یک کد کندتر از اجرای کد ترجمه شده است، زیرا مفسر باید هر دفعه که برنامه شروع به اجرا می‌کند، همهٔ عبارت‌های آن را تحلیلanalyze کند و سپس عملیات مورد نظر را اجرا کند در حالی که کد ترجمه شده فقط عبارتها را اجرا می‌کند. دسترسی به متغیرها نیز در مفسر کندتر است؛ زیرا مسیردهی شناسه به محل ذخیره‌سازی در زمان اجرا نسبت به زمان ترجمه به دفعات بیشتری صورت می‌گیرد. | ## بخش 2: مفسر (رایانش) | سازش‌های زیادی بین سرعت تولید به هنگام استفاده از مفسر و سرعت اجرا به هنگام استفاده از مترجم وجود دارد. برخی سیستم‌ها (برای مثال، ال آی اس پیLISPs) به کدهای ترجمه شده و تفسیر شده اجازه می‌دهند تا یکدیگر را فراخوانی کنند و متغیرهایشان را به اشتراک بگذارند. به این معنا که هنگامی که یک روال تحت یک مفسر مورد تست قرار گرفت و اشکال‌زدایی شد، می‌تواند ترجمه شود و بنابراین، در حین اینکه روال‌های دیگر در حال تولید شدن هستند، اجرای سریعتری داشته باشد. تعداد زیادی از مترجم‌ها کد منبع را همان گونه که هست اجرا نمی‌کنند بلکه آن را به نوع فشرده تر داخلی تبدیل می‌کنند. برای مثال، برخی از مفسرهای ابتدایی، کلمات کلیدی را با نشانه‌های تک بایتی -که می‌توانند برای یافتن دستورالعمل‌ها در یک میز جامپjump table استفاده شوند- جایگزین می‌کنند. مفسرهای بایت کد طیفیspectrum از احتمالات بین تفسیر کردن و ترجمه کردن وجود دارد که به مقدار تحلیل انجام شده قبل از اجرای برنامه بستگی دارد. برای مثال، ایماکس لیسپEmacs Lisp به بایت کد -که نمایندهٔ بسیار بهینه شده و فشرده شده‌ای از منبع لیسپ است، ولی کد ماشین نیست (و در نتیجه وابسته به سخت‌افزار مشخصی نیست) -ترجمه می‌شود. کد ترجمه شده در این حالت، یک کد ماشین برای یک ماشین مجازی است، که در سخت‌افزار پیاده‌سازی نشده و در مفسر بایت کد پیاده‌سازی شده است. مفسرهای درخت نحو انتزاعی در طیف بین تفسیر کردن و ترجمه کردن، روش دیگری نیز وجود دارد. | ## بخش 3: مفسر (رایانش) | در این روش، کد منبع به یک درخت نحو انتزاعی بهینه شده تبدیل می‌شود و سپس به تبعیت از این ساختار درختی، برای اجرای برنامه اقدام می‌شود. به عنوان یک مزیت نسبت به بایت کد، این روش ساختار برنامهٔ سراسری و رابطهٔ بین عبارات را (که در بایت کد از بین می‌رود) حفظ می‌کند و یک نمایش فشرده تر را فراهم می‌سازد؛ بنابراین، درخت انتزاعی ترکیب، به عنوان یک قالب میانی بهتر نسبت به بایت کد برای مترجمهای داخل زمانی پیشنهاد شده است. ثابت شده است که یک مفسر جاوا مبتنی بر درخت انتزاعی ترکیب، از یک مفسر مشابه مبتنی بر بایت کد سریع تر است. این سرعت بیشتر به خاطر بهینه‌سازی قویتر است که این بهینه‌سازی به دلیل برخورداری از ساختار کامل برنامهٔ موجود در حین اجرا، به وجود می‌آید. این برمی گردد به کارایی اجرای کد بومی در سریع کردن زمان بالا آمدن و افزایش استفاده حافظه، هنگامی که در ابتدا بایت کد ترجمه می‌شود. هر دو تکنیک بیش از چند دهه سن ندارند، به‌طوری‌که نخستین بار در زبان‌هایی مانند اسمال تاک در ۱۹۸۰ بکار برده شدند. ترجمه داخل زمانی در سال‌های اخیر، توجه بسیاری از مهندسان نویسنده زبانهای برنامه‌نویسی را به خود جلب کرده است. | ## جمع‌بندی | ای بی ام ۵۵۰IBM 557 مفسر عددی و ای بی ام ۵۵۷IBM 550 مفسر الفبایی، نمونه‌هایی از این نوع هستند که به ترتیب در سال‌های ۱۹۳۰ و ۱۹۵۴ ساخته شده‌اند.