جستجو در تالارهای گفتگو
در حال نمایش نتایج برای برچسب های 'مترجم'.
4 نتیجه پیدا شد
-
نگارش 10.2.0
60 دریافت
مجموعه کدمترجمهای گنو یا «کلکسیون کامپایلرهای گنو» (GNU Compiler Collection) که به اختصار GCC نیز خوانده میشود، مجموعهای از کامپایلرها برای زبانهای برنامهنویسی مختلف است که بوسیله پروژه گنو بوجود آمده است. جیسیسی یکی از کلیدیترین اعضای سلسلهبرنامههای گنو (به انگلیسی: Gnu ToolChain) است. جی سی سی در ابتدا فقط کامپایلری استاندارد برای سیستم گنو بود ولی امروزه در بسیاری از سیستمعاملهای مشابه یونیکس از آن استفاده میشود؛ مانند گنو/لینوکس، خانواده بیاسدی، اواس ایکس. همچنین جیسیسی برای معماریهای سختافزاری مختلف نیز پورت شده است. جیسیسی در اوایل سرنام کلمات GNU C Compiler بود. زیرا فقط توانایی کامپایل برنامههای نوشته شده به زبان C را داشت؛ که با مرور زمان قادر به ترجمه زبانهای بیشتری مانند سیپلاسپلاس، فورترن، پاسکال، جاوا، آبجکتیو سی و ایدا شد. پس از آن جی سی سی سرنام کلمات GNU Compiler Collection شد. بنیاد نرمافزارهای آزاد جیسیسی را تحت اجازهنامه آزاد گنو (جیپیال) نسخه ۳ به انضمام استثناهای منحصر به جیسیسی منتشر کردهاست.رایگان
-
با سلام، یا توجه به مقالهٔ ذکر شده زیر در ارتباط با انتخاب زبان برنامهنویسی و تفاوت عمدهٔ زبانهای کامپایلری و مفسری لازم است تعاریفی در رابطه با جزئیات زبانهای کامپایلری که خود تفاوتهایی را شامل میشوند بپردازیم. در صورتی که مقالهٔ زیر را مطالعه نکردهاید پیشنهاد میکنیم قبل از خواندن این مقاله آن را مرور کنید. در این مقاله شما تفاوت عمدهٔ آنها را خواهید آموخت که شامل توضیحات کامپایلر و روشهای کامپایل میباشد. کامپایلر چیست؟ کامپایلر به ابزار (برنامه یا مجموعهای از برنامهها) گفته میشود، که متنِ نوشته شدهٔ برنامهنویسان (در قالب کُد) را که از سطح بالاتر (زبان مبدأ) برخوردار است و درک آن برای انسان مُیسر میباشد، دریافت کرده و آن را به زبان سطح پایینتر (زبان مقصد) مانند اسمبلی یا کُد ماشین ترجمه میکند. زبانهای کامپایلری در دو دستهی بومی (Native) و مجازی (Virtual) کامپایل از نوع بومی روشی است که کدهای نوشته شده را به صورت مستقیم به کُد ماشین ترجمه میکند. کامپایل از نوع مجازی روشی است که کدهای نوشته شده را ابتدا به کُدمیانی (کدمشترک یا همان بایت کُد - Byte Code) در جاوا و زبان میانی (CIL) در Net. تبدیل میکند که خودِ آن شبیه به کُد ماشین است. در این فرایند کد مربوطه توسط کامپایلر مخصوص یعنی JIT (کامپایلری از نوع Just-In-Time) در زمان اجرا توسط سیستمعامل، به دستورالعملهای قابل فهم برای پردازنده تفسیر و اجرا میشود (که این فرایند شبیه به فرایند عملکرد اجرایی مفسرها است). زبانهای بومی (زبانهایی که کد آنها به کد ماشین به صورت مستقیم توسط کامپایلر قبل از اجرای آنها توسط سیستمعامل، ترجمه میشوند که به اصطلاح ahead-of-time (جلوتر از زمان) یا همان AOT نام دارد) مانند: C, C++, Rust, Haskell, Clean, Swift, Go, Fortran, D زبانهای مجازی (زبانهایی که کد آنها توسط یک رابط میانی به زبان مشترک ترجمه میشود) : Java و خانوادهٔ داتنت مانند C#, Visual Basic.Net و C++/CLR نکته قابل توجه در مورد C++/CLR آن است که این نوع استاندارد در مورد سیپلاسپلاس بر پایهٔ چهارچوب داتنت است. در این نسخه از زبان شما با محدودیتهای بسیاری مواجه بوده و به ویژگیها و کیفیت نهایی برنامههای تولید شدهٔ واقعی در قالب Native محروم خواهید بود. روش کامپایل و و انواع آنها کامپایلرها به صورت بومی (Native) و کراس (Cross) تقسیم بندی میشوند. به طور کلی آن دسته از کامپایلرها که کدهای باینری را تولید میکنند از نوع محلی یا همان Native نام دارند؛ در واقع به هر کامپایلی که بر روی سیستمهای معماری x86 نوع x86، بر روی سیستمهای x86-64 نوع x86-64 و بر روی سیستمهای PowerPC نوع powerpc و بر روی arm نوع arm را تولید کند کامپایل بومی میگویند. چرا که تنها برای یک پلتفرمِ هدف کدهای ماشین رو تولید خواهد کرد (در صورت نیاز برای اجرا بر روی پلتفرمهای دیگر باید آن را بر روی پلتفرم متناسب با آن پیکربندی کنید) در واقع یک وابستگی به سختافزار وجود خواهد داشت که کدهای شما بر اساس آن تولید میشود. اما در رابطه با کامپایلرها از نوع Cross یا به اصطلاح عبوری وابستگی خاصی به سختافزار ندارند، در این روش کافی است سختافزار، پلتفرم (معماری و سیستمعامل) مورد نظر را یک بار برای آن معرفی کرده و اقدام به کامپایل کنید. کامپایل به صورت کراس کدها را به برنامهٔ قابل اجرا برای بیشتر از یک پلتفرم فراهم میکند. برای مثال در صورتی که بر روی پلتفرم ویندوز هستید میتوانید برنامهٔ نوشته شدهٔ خود را برای پلتفرم اندروید یا آیاواس که برای arm هستند ارائه دهید. اولین کامپایلری که این ویژگی را پشتیبانی میکند GCC است. این امکان وجود دارد که شما کدهای نوشته شدهٔ خود را بر روی پلتفرم میزبان برای پلتفرمهای هدف (مقصد) کامپایل کنید. البته جدیداً کامپالر کلَنگ (Clang) به عنوان یکی از بهترین انتخاب بین برنامهنویسان ++C جهت کراسکامپایل مطرح میشود. کامپایلرهای پیشنهادی: GCC Clang MSVC مزایا و معایب زبانهای کامپایلری از نوع کلاس بومی (Native) از سرعت بسیار بالایی برخوردار هستند (دلیل آن ترجمهٔ مستقیم کدها به کد ماشین است) در مقابل بزرگترین مزیتی که زبانهای نوع کلاس مجازی (Byte Code) دارند به خاطر وجود یک برنامهٔ واسط جهت شبیهسازی کدهای ترجمه شده به کد قابل فهم برای پردازنده، اجرا شدن آنها در هر پلتفرم بدون کامپایل مجدد امکان پذیر است که البته این ویژگی خود نیازمند نصب بودن JVM بر روی پلتفرم مربوطه میباشد. در نوع بومی برای اجرا در هر پلتفرم لازم است سورس کدها را برای پلتفرم مقصد کامپایل کنید که نیازی به وجود ماشین مجازی مانند JVM یا برنامهٔ خاصی ندارد. کدهای میانی تحت کامپایلِ درجا JIT : Just In Time همانطور اشاره شد زبانهای برنامهنویسی Java و خانوادهٔ Net. به ترتیب توسط Java Byte Code بر روی ماشین مجازی جاوا JVM و CIL : Common Intermediate Language بر روی زیر ساخت CLI : Common Language Infrastructure از هم جدا میشوند. در نظر داشته باشید CIL نام تغییر یافتهٔ MSIL میباشد. معنای ماشین مجازی CLR و JVM جیویام یا همان JVM : Java virtual machine نوعی ماشین مجازی (واسطی) است که وظیفه اجرای کد جاوا را برعهده دارد. زمانی که در مورد برنامههای نوشته شده توسط جاوا صحبت میکنیم، حتما باید JVM بر روی سیستم شما نصب باشد تا قابلیت اجرا شدن برنامههای تحت جاوا را داشته باشد. سیاِلآر یا همان CLR : Common Language Runtime نوعی ماشین مجازی (واسطی) است که کدهای مربوط به CIL را برای سیستم تفسیر و اجرا میکند. البته تفاوتهایی در خروجی این کد با کدهای جاوا وجود دارد که در آن زبان IL به عنوان یک زبان شبیه به زبان ماشین مانند اسمبلی (assembly) میباشد. در CLR کدهای تولید شدهٔ بایتکد، کمتر از دستورالعملها و ابردادههای JVM است. تفاوت اصلی CLR و JVM تفاوت اصلی JVM و CLR در این است که JVM جهت اجرای کدهای جاوا استفاده میشود و CLR مدیریت برنامههای اجرایی داتنت را مدیریت میکند. به طور کلی، JVM امکان اجرای کدهای کامپایل شدهی جاوا را فراهم میکند که در بسیاری از سیستمعاملها و سختافزارها موجود است. از سوی دیگر، CLR یک بستر (محیطی) را برای اجرای برنامههای نوشته شده در چهارچوب داتنت همراه با امکان مدیریت حافظه، مدیریت خطاها، امنیت و غیره را فراهم میکند. نسل جدید JIT برای داتنت (نام کد RyuJIT) به لُطف Net. و نسخهٔ Net Core. نام RyuJIT کُد شناسه از کامپایلر Net. است که وظیفهٔ آن ترجمهٔ کدهای #C به بایتکُد IL است که RyuJIT کدهای بایتکُد از نوع IL را به کُد ماشین ترجمه میکند. همانطور که مشخص است، جهان به سمت محاسبات ۶۴ بیتی حرکت میکند، اما باید در نظر داشته باشید سرعت برنامههای ۶۴ بیتی همیشه بیشتر از ۳۲ بیتیها نمیباشد! برای مثال نمونهای از آن را میتوان به کامپایلر JIT برای داتنت مثال زد؛ تغییرات و بهبودهایی که در نسل بعدی کامپایلر JIT بر روی Net Core. صورت گرفته است نسخهٔ ۶۴ بیتی آن است که اجازه میدهد برنامهها دو برابر سریعتر از نسخهٔ قبلی خود در داتنِت اجرا شود. این امر باعث میشود که نظرات شما را در مورد این نسخه از کامپایلر داتنت تغییر دهد. همانطور که به نظر میرسد، معماری ۳۲ بیتی x86 کامپیوترها که از زمانهای ایجاد تا به کنون در نوع خود بسیار عالی بودهاند، اما مشکل بزرگی که دارند متاسفانه پشتیبانی تا حداکثر ۴ گیگابایت حافظهٔ اصلی (Ram) است. با توجه به رُشد روز افزون معماری ۶۴ بیتی x64 نیاز به حافظههای بیش از ۴ گیگابایت جدی شد و امروزه ما میبینیم که اکثر سختافزارها و حتی دستگاههای موبایل نیز مجهز به حافظههای بیش از ۴ گیگابایت هستند. برای بهرهمندی از قابلیتهای معماری جدید Net Core. کامپایلر خود را با بهینهسازیهای چشمگیری ارائه داده است که میتواند تا دو برابر سریعتر از نسل قبلی خود عمل کند. در نظر داشته باشید که، معماری RyuJIT تقریبا نه سال پیش طراحی شده است و کارهای اجرایی از هفت سال پیش آغاز شده است. RyuJIT به عنوان یک کامپایلر تکامل یافته از JIT32 موجود (که از x86 و ARM32 پشتیبانی میکند) اجرا شد و به تدریج جایگزین بسیاری از بخشهای "بَکاِند" آن کامپایلر با یک تخصیص دهندهٔ رجیستر جدید و تولید کنندهٔ کد همراه با برخی از ویژگیهای جدید و بهبود یافته در "فرانتاِند" برای بهینه سازی در اجرا معرفی شده است. در طول این انتقال به کدهای نسل جدید معماری، سعی بر این بوده است که کدهای نسل قبل را در کنار نسل جدید نگه داشته شود. انجام این کارها مزایایی داشته است مانند حفظ هزینهها و باز نویسیهای بسیار! اما مسلماً هزینههایی هم دربر داشته است که کمترین آنها سردرگم بودن توسعهدهندگان در بارهٔ آیندهٔ Jit بوده است. در حال حاضر عملکرد RyuJIT برای کدهای قدیمی بسیار خوب بوده است و سرانجام وقت آن رسیده است که کدهای نسل قبل در JIT در آیندهای نزدیک تمرکز شود. نسل جدید از JIT با تمرکز بر پشتیبانی از معماری ۶۴ بیتی با نام RyuJIT سریعتر از JIT64 است. زبانهایی که از JIT/CLR پشتیبانی میکنند زبانهای اصلی این کامپایلر C#, VB.Net و C++ Managed یا همان C++/CLR میباشند. نکته: سی++ در این نسخه تغییراتی از جانب مایکروسافت داشته است و از نسخهٔ استاندارد آن کمی متفاوت است. برای مثال مدیریت حافظه به صورت خودکار و همچنین تغییرات جزئی از قبیل سینتکس را دارا میباشد. ساختار برنامههای زبان کامپایلری از نوع بومی (Native) در زبانهای مادر C و ++C در صورتی که تمایل دارید در رابطه با جزئیات ساختار برنامههای سریعترین زبانهای برنامهنویسی یعنی C و ++C مطلع شوید توصیه میشود مقالهٔ مرتبط با آن را که در زیر آمده است مطلعه کنید.
-
- مترجم
- machine code
-
(و 14 مورد دیگر)
برچسب زده شده با :
-
سلام، آیا ممکن هست در مورد منطق، ساختار و اساس کاریِ کامپایلر و همچنین تعامل آن با سیستم عامل (پلتفرمهای) مختلف توضیحاتی ارائه دهید؟ با سپاس.
-
کامبیز اسدزاده یک موضوع را ارسال کرد در <span class="ipsBadge ipsBadge_pill" style="background-color: #e62f3d; color: #ffffff;" >برنامه نویسی در C و ++C</span>
مراحل ساخت برنامه در زبان سیپلاسپلاس پیش نویس ۰.۶ قبل از هر چیز به اینفوگرافی زیر توجه کنید که مراحل ساخت برنامه در سیپلاسپلاس را نشان میدهد. مقدمهای بر همگردانی (کامپایل) و اتصال (لینک کردن) این سند مرور مختصری در رابطه با مراحل را برای شما فراهم میکند تا به شما در درک دستورات مختلف برای تبدیل و اجرای برنامهٔ خودتان کمک کند. تبدیل مجموعهای از فایلهای منبع و هدر در سیپلاسپلاس به یک فایل خروجی و اجرایی در چندین گام (به طور معمول در چهار گام) پیشپردازنده (Preprocessors)، کامپایل و گردآوری (Compilation)، اسمبلر (Assmbler) و پیوند دهنده (Linker) تقسیم میشود. قبل از هر چیز اگر در محیط توسعهٔ Qt Creator داخل فایل .pro مقدار زیر را وارد کنید، تا بتوانید فایلهای ساخته شدهٔ موقت در زمان کامپایل را مشاهده کنید. QMAKE_CXXFLAGS += -save-temps این دستور اجازهٔ آن را خواهد داد تا فایلهایی با پسوند .ii و .s در شاخهٔ بیلد پروژه تولید شوند که در ادامه به آنها اشاره شده است. تعریف پیشپردازنده پیشپردازندهها (Preprocessors) درواقع دستوراتی هستند که اجازه میدهند تا کامپایلر قبل از آغاز کردن مراحل کامپایل دستوراتی را دریافت کند. پیشپردازندهها توسط هشتگ (#) مشخص میشوند این نماد در سی++ مشخص میکند که دستور فوق از نوع پیشپردازنده میباشد که نتیجهٔ آن در قالب ماکرو (Macro) در دسترس خواهد بود. برای مثال ماکروی __DATE__ توسط پیشپردازندهها از قبل تعریف شده است که مقدار تاریخ و زمان را بازگشت میدهد. بنابراین هرکجا که از آن استفاده شود کامپایلر آن را جایگزین متن خواهد کرد. در شکل زیر مرحلهای که از پیشپردازندهها استفاده میشود آمده است: پیشپردازنده، کامپایل (گردآوری کردن)، لینک (پیوند کردن) و ساخت برنامه اجرایی فرایند تبدیل مجموعهای از فایلهای متنی هِدر و سورس سی++ را «ساخت» یا همان Building میگویند. از آنجایی که ممکن است کُد پروژه در بسیاری از فایلها هدر و سورس سی++ توسعه و گسترش یابدمراحل ساخت در چند گام کوچک صورت میگیرد. یکی از رایجترین موارد در مراحل گردآوری (ترجمهٔ یک کد سیپلاسپلاس به دستورالعملهای قابل فهم ماشین) است. اما گامهای دیگری نیز وجود دارد، پیشپردازنده و لینک (پیوندها) این بخش به طور خلاصه توضیح میدهد که چه اتفاقی در هر یک از مراحل رُخ میدهد. یک کامپایلر یک برنامهٔ خاص است که پردازش اظهارات (دستورات) نوشته شده در یک زبان برنامهنویسی خاص را به یک زبان ماشین که قابل فهم برای پردازنده میباشد تبدیل کند. به طور معمول یک برنامهنویس با استفاده از یک ویرایشگر که به محیط توسعهٔ یکپارچهٔ نرمافزار (IDE) مشهور است توسط زبان برنامهنویسی مانند ++C دستورات (اظهارات) را مینویسد. فایل ایجاد شده با نام (filename.cpp در زبان برنامهنویسی سیپلاسپلاس) شامل محتوایی است که معمولاً به عنوان دستورات برنامهنویسی سطح بالا نامیده میشود. سپس برنامهنویس کامپایلرِ مناسب برای زبان برنامهنویسی مانند سی++ را اجرا میکند و نام فایلهایی که حاوی دستورات هستند را برای کامپایل مشخص میکند که این انتخاب و مشخص سازی توسط IDE به راحتی قابل مدیریت است. پس از آن، کار کامپایلر این است که فایلهای منبع .cpp را جمع آوری کرده و پیشپردازندهها را بررسی کند تا دستورات احتمالی را اجرا نماید که نتیجهٔ این مرحله در فایلی با پسوند .ii ر قالب filename.ii تولید میشود که در این فرایند نیز خط به خط کُدهای موجود در آنها را بررسی میکند تا خطاهای احتمالی نحو (سینتکس - Syntax) بررسی میشود و آنها را به طور ترتیبی به دستورالعملهای سطح ماشین تبدیل کند. توجه داشته باشید که هر نوع پردازندهٔ کامپیوتر دارای مجموعهای از دستورالعملهایِ ماشین خودش است. بنابراین کامپایلر تنها برای سی++ نیست، بلکه برای اهداف و مقاصد خاص هر پلتفرم است. پس کدهایی که توسط پیشپردازنده سیپلاسپلاس به زبان اسمبلی برای معماری مورد نظر در پلتفرم مقصدترجمه شدهاند نتایج آن در فایلی با پسوند .ss در قالب filename.ss قابل نمایش هستند که در حالت عادی قابل رویت نیست. توجه داشته باشید که باید در این مرحله باید مشخص شود برنامه قرار است توسط چه نوع پردازندهای تحتِ چه نوع معماری مونتاژ (اسمبل) شود. برای مثال پردازندهها با انواع معماریهای مختلف وجود دارند که برخی از آنها به صورت x86-x64، x64، ARMv7، aarch64 غیره ... میباشند. شکل یک (کامپایل یک فایل منبع ++C) مرحلهٔ سوم را در نظر داشته باشید که عمل کامپایل فایل سیپلاسپلاس در دو مرحله قبلی یک فایل اجرایی را تولید نمیکند. برنامهای که توصیف شده است، احتمالاً توابعی را در رابطهای برنامهنویسی (API) و یا توابع ریاضی یا توابع مرتبط با I/O را فراخوانی کند که ممکن است شامل فایلهای هدر مانند iostream یا fstream و حتی ماژولهای دیگری که در زبان تعبیه شدهاند را داشته باشد که فایل تولید شده توسط کامپایلر در این مرحله یک فایل شیء نامیده میشود که با پسوند .o به صورت filename.o تولید خواهد شد که علاوه بر دستورالعملهای تبدیل شده به کد ماشین، شامل توابع و دستورالعملهای خارجی نیز میباشد. هرچند در این مرحله دستورات تبدیل به دستورالعملهای قابل فهم توسط پردازنده شدهاند اما فعلاً قابل اجرا نیستند چرا که باید این توابع خارجی افزوده شده را به آن لینک کرد که در مرحلهٔ بعد یعنی مرحلهٔ چهارم اتفاق میافتد. در نهایت مرحلهٔ چهارم فایل با پسوند .o که شامل کدهای تولید شده توسط کامپایلر به زبان ماشین است که پردازندهها میتوانند این دستورات را درک کنند که همراه با کدهای تولید شدهٔ هر کتابخانهٔ دیگری که مورد نیاز است توسط لینکر (لینک شده) و در نهایت جهت تولید یک فایل اجرایی مورد استفاده قرار میگیرند که نوع آن فایل از نوع اجرایی یا در واقع Executable File خواهد بود. شرح کامل فرایند ساخت فایل اجرایی اکثر پروژهها دارای مجموعهای از فایلهای هدر سی++ هستند، که امکان ماژولار شدن در آن را فراهم میکند و مجموعهای از آن میتواند به عنوان بخشهای کوچکی از برنامه محسوب شوند. برای ساخت چنین پروژههایی هر فایل سیپلاسپلاس باید کامپایل شود و سپس فایلهای ساخته شده در قالب شیء (آبجکت) باید همراه توابع و کتابخانههای دیگر لینک (پیوند) شوند. البته هر گام از مراحل کامپایل شامل یک مرحله پیشپردازنده است که دستورالعمل # عمل تغییرات و اصلاحیهها را در فایل متن اعمال میکند. شکل زیر فرایند ساخت چند فایل به صورت همزمان را نشان میدهد: در ادامهٔ این مقاله، مطلبی مرتبط با تنظیمات بیشتر از کامپایلر آمده است که میتوانید آن را مورد مطالعه قرار دهید.