بررسی رابطه بین معماری و برنامه مترجم (کامپایلر) An examination of the relation between architecture and compiler

من وهمکارانم در بهبوهه تلاش تحقیقاتی هستیم که هدف آن اتوماتیک کردن ایجاد  کامپایلر های کیفی تولیدی می باشد. ( برای محدود کردن آنچه که قبلا به نام پروژه بلندپروازانه بوده است، ما تنها زبان جبر و کامپیوترهای معمولی را مد نظر قرار می دهیم.) به طور مختصر، بر خلاف بسیاری از کامپایلرها- یعنی تلاش برای کامپایل کردن در گذشته- فعالیت های شامل اتوماتیک کردن تمام مراحل کامپایلر – شامل مرحله بهینه سازی و ایجاد کد که در بهینه سازی کامپایلرها یافت می شود، می باشد. تنها اطلاعات ورودی مربوط به این فرایند تولید، تعریف رسمی از زبان مبدا و کامپیوتر هدف می باشد. ایجاد الگوریتم کامپایل که به همراه پارامترهای مناسب می باشد، در مجموعه گسترده ای از  طرح های کامپیوتری بازدهی داشته و برای این تحقیق مهم می باشد. در عوض، مد نظر قرار دادن این الگوریتم ها ما را به طور مشخصی به این سمت می کشاند تا بسیاری از طرح ها  و مشکلاتی را که آن ها ایجاد می کنند، مورد بررسی قرار دهیم. بسیاری از عقایدی که مطرح می گردد، بر مبنای تجاربمان برای انجام این فرایند و با توجه به مشکلاتی که ما با آن ها روبرو می باشیم، می باشد.

 مقاله های مربوط به این دست با مد نظر قرار دادن این مورد آغاز می گردد که جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. در حالی که هزینه نرم افزار رو به بالا می باشد. نتیجه اجتناب ناپذیر این می باشد که می بایست روش هایی را برای سخت افزار به منظور ساده کردن فعالیت نرم افزاری پیدا کنیم. یکی از روش هایی که می توان چنین کاری را انجام داد، طراحی مجموعه دستورالعمل هایی می باشد که به بازتاب نیازهای مربوط به زبان های برنامه نویسی سطح بالا می پردازد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. دلیل چنین فرایند غیرمتعارفی حقیقاتا این می باشد که اشتیاق ما بسیار سریعتر از فناوری که در مسیر ایجاد رضایت پیش می رود، می باشد. سیکل زمانی بیشتری ، حافظه بیشتر، دیسک های سخت و موارد بیشتری مورد نیاز می باشد تا آنچه را که یک کاربر معمولی می خواهد و انتظار دارد، ایجاد کنیم. به نظر من این فعالیت خوب می باشد؛ و با وجود عملکرد سطح پایین، سیستم دارای پاسخ دهی بیشتری نسبت به تمام نیازها می باشد- یعنی کاربر پسندتر می باشد. به این ترتیب مزایایی در ارتباط با کارایی برنامه هایی که به اجرا در می آید وجود دارد. گذشته همیشه به عنوان ایمن ترین عامل پیش بینی کننده آینده می باشد حداقل اگر ما آن را به طور مناسبی تفسیر کنیم. اگرچه هزینه های سخت افزاری به طور قابل توجهی پایین آمده و همزمان سرعت تجهیزات به طور قابل توجهی بالا می رود، فرض ما این می باشد که اشتیاق ما حتی بیش از این بالاتر می رود. به این دلیل، ما با مازاد چرخه یا حافظه مواجه نمی باشیم. در آینده نزدیک، تاثیر غالب تنها هزینه تجهیزات یا سرعت نمی باشد، اما در ارتباط با تلاش مستمر به منظور افزایش منافع از منابع محدود می باشد- یعنی کامپیوتر خاصی که در اختیار ما قرار دارد. این به اصلاح بر مینای "صرفه جویی امریکایی" نمی باشد. در ارتباط با سیستم ها، مردم نیازی به ارتقا آن ها داشته تا پاسخ دهی بهتری نسبت به نیاز بشری داشته باشند. ناکارایی هایی که این ایده آل ها را متوقف می کند، تحمل نمی شود.

رابطه هزینه

قبل از بحث در مورد تاثیر متقابل کمپایلرها و طرح های تجهیزات هدف، ما می بایست اهداف این فعالیت ها را مد نظر قرار دهیم. هزینه ها و بلعکس مزایا مد نظر قرار می گیرند.

آن ها شامل:

طراحی ( نوشتن) کامپایلر

- طراحی معماری سخت افزار

- طراحی اجرای سخت افزار آن معماری ها

- تولید سخت افزار ( یعنی کپی برداری مراحل اجرا)

- ارایه کامپایلر، و

اجرای برنامه های کامپال شده.

اهمیت نسبی این هزینه ها برمبنای نصب و کاربرد می باشد- که فرد نمی تواند به بیان اهمیت نسبی این موارد بدون اطلاعات مشخص تر بپردازد. علاوه بر این مشاهدات کلی نیز وجود دارد که بر مبنای موارد پیش رو می باشد.

در ابتدا توجه داشته باشید که تنها مورد چهارم، هزینه ایجاد سخت افزار، به طور قابل توجهی کاهش می یابد. در حالی که تراشه های استاندارد MSI و LSI به منظور کاهش هزینه طراحی سخت افزار به کار گرفته می شوند، مهندسی کامل پردازشگر بر روی تراشه مجزا منجر به افزایش مجدد آن می گردد. طراحی ساختارهای نامنظم در سطح تراشه خیلی هزینه بردار می باشد.

دوم اینکه، تمام فعالیت های طراحی، ( کامپایل، طراحی های و اجرا) هزینه های واحدی می باشند. از نقطه نظر مشتری، آن ها بر مبنای تعداد موارد یکپارچه فروخته می شوند. بنابراین طراحی یک معماری دارای واکنش بیشتری نسبت به مشکلات کامپایل می باشد، حتی اگر کاهش در هزینه نوشتن کامپایل، اجرای آن، یا اجرای کد نوشته شده توسط آن، به جبران افزایش هزینه طراحی بپردازد. اغلب این موارد به آسانی قابل انجام می باشد، که بعدا توضیح داده می شود. به هر حال باید به یاد داشته باشیم که طراحی سخت افزار نسبت به طراحی نرم افزاری که چنین کاری را انجام می دهد پرهزینه تر می باشد، مگر اینکه عالیت خیلی ساده باشد. این توضیح می دهد که چرا برای نمونه انتقال کل کامپایلر به سمت سخت افزار مفهومی نمی باشد.  سوم، هر دو مورد یعنی طراحی و نرم افزار اساسا دارای عمری بیشتر از فناوری سخت افزار که در ابتدا به مرحله اجرایی در می آیند، می باشد. با وجود سقوط قابل پیشبینی در هزینه سخت افزاری، اغلب موارد الگوهایی طراحی می گردد که خلاف قاعده فناوری غالب در زمانی که طراحی می شوند را نشان می دهند. در واقع، اختلالی بین هزینه های دوم و سوم موارد لیست شده در بالا وجود دارد.

در نهایت، دو مورد آخر، یعنی هزینه کامپایل و اجرای برنامه ها به طور دقیق در مقایسه با مواردی که به دنبال آن می آیند نیست. البته هزینه های دلاری نسبت به این موارد اختصاص داده می شود.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

البته، در اغلب موارد، ارزیابی صحیح از نقطه نظر دلاری نمی باشد ما از نقطه نظر مواردی می باشد که نمی تواند در نتیجه کامپایل یا ناکارایی اجرا مد نظر قرار گیرد. موارد نصبی معمولی تنها هر از گاهی نیاز به کامپیوتر جدید دارد ( و ضررهای مربوط به انجام این کار را تحمل می کند). در ارتباط با مالکیت کامپیوترهای در دسترس منابع ثابت و محدودی وجود دارد. از این رو، ناکارآمدی در فرایند کامپایل و مراحل اجرا خودش را بر مبنای کاهش بازدهی، عملیات غیر قابل دسترسی، و هزینه های مشابه، آشکار می کند. اگرچه ارزیابی این موارد مشکل می باشد، این هزینه ها دارای تاثیرات درجه اولی می باشند که مد نظر کاربران قرار می گیرد زمانی که تجهیزاتی خریداری می گردد.

بعضی از اصول کلی

- اصولی که باعث بهبود انطباق بین کامپایلرها و کامپیوتر هدف می گردد در بسیاری از طرح های همزمان دنبال می گردد:

- نظم. اگر چیزی به یک روش و در یک جا انجام پذیرد، در جاهای دیگر نیز به همان روش انجام می شود. این قانون در جامعه طراحی زبان برنامه نویسی به نام " قانون حداقل سرگشتگی " می باشد.

تعامد. این احتمال وجود دارد تا مشخصات تجهیزات ( مشخصات زبان برنامه نویسی) را به مجموعه ای از موارد مجزا تقسیم کرده و هر یک از این موارد را مجزا از موارد دیگر تعریف کنیم. برای نمونه این احتمال وجود دارد تا به بحث انواع اطلاعات، آدرس دهی و مجموعه دستورالعمل ها به طور مستقل بپردازیم.

- توانایی ساخت. اگر اصول مربوط به قاعده و تعامد دنبال گردد، سپس این احتمال به وجود می آید تا تعامد و مفاهیم منظمی را به روش های قراردادی ایجاد کنیم. برای نمونه، مد نظر قرار دادن روش ادرس دهی با هر اپراتور و هر نوع اطلاعات.

به هر حال این اصول به طور کاملی دنبال نمی گردد، و انحراف از آن ها برای مولف کامپایلر بعضی از مشکلات را ایجاد می کند. چندین اصل دیگری نیز در زیر وجود دارد که که در زیر به آن اشاره می کنم.

قبل از بیان ان ها به من اجازه بدهید تا موارد پیشین را توضیح دهم.

اگرچه بهینه سازی کامپایلر از نقطه نظر فعالیت های سطحی و عمقی همانند تجزیه و تحلیل گردشی و ساده سازی جبری مد نظر قرار می گیرد- در واقع چنین تکنیک هایی حقیقتا به هدف اجرای تجزیه و تحلیل های موردی بیشماری می باشند. هدف تعیین بهترین کد مقصود برای برنامه منبع مورد نظر می باشد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

مد نظر قرار دادن فعالیت کامپایلر به عنوان یک تجزیه و تحلیل موردی بزرگ کمکی به توضیح این مورد می کند که چرا قواعد، تعامد و مسئولیت برای ساده سازی فعالیت مهم می باشند. انحراف از این اصول به عنوان یک مورد تک منظوره مد نظر می باشد. و افسوس که مد نظر قرار دادن موارد خاص محدود به مرحله انتخاب کد نمی باشد؛ زیرا هر فاز آماده سازی نیازمند ارائه رابط اطلاعاتی خاصی می باشد، این آشکار سازی غیرعادی تقریبا از طریق تمام این موارد برگشت داده می شود. من سعی می کنم این موارد را با نمونه های بیششتری در بخش بعدی توضیح دهم. در حال حاضر، به هر حال، نوع دستگاه ثبت کلی را مد نظز قرار دهید. این موارد نشان می دهد که موارد ثبت شده به صورت کلی می باشند- ، یعنی ان ها می توانند با هر هدفی که موارد ثبت شده بر روی تجهیزات قرار می گیرند، مورد استفاده قرار گیرند. در واقع، به هر حال، تقریبا هیچ دستگاهی نمی تواند تمام موارد ثبتی را به طور یکپارچه مد نظر قرار دهد- یعنی موارد مضروب می بایست به صورت ثبت شده بوده یا دستورات اجرایی با دقت مضاعف می بایست در مجموعه تصادفی قرار گیرد یا صفر در زمینه فهرست سازی یک دستور نشان دهنده هیچ شاخص گذاری نبوده ( و از این رو موارد ثبت شده صفر برای شاخص گذاری مورد استفاده قرار نمی گیرد)، یا بعضی از فعالیت ها تنها بین موارد ثبت شده به اجرا در آمده در حالی که موارد دیگر تنها بین موارد ثبت شده و حافظه یا متغیرهای دیگر به اجرا در می آید. هر یک از این تمایزها تخلفی از یک یا چند اصول بالا بوده و منجر به پیچیدگی بیشتری می گردد.

بعضی از اصول مشخص تر دیگر عبارتند از

- یکی در برابر همه، به طور مشخصی یک راه برای انجام کارها وجود دارد یا تمام روش ها امکان پذیر می باشد.

- فراهم کردن مقدمه و نه راه حل. بهتر می باشد تا موارد مقدماتی را که از آن راه حل هایی برای ایجاد کد ترکیب می گردند نسبت به مد نظر قرار دادن خود راه حل، فراهم کنیم.هر دو این موارد در ارتباط با سادگی ( نه پیچیدگی) تجزیه و تحلیل موردی کامپایلرمی باشد. اصل یکی در برابر همه را مشاهده کنید. هر یک از این دو موقعیت نشان می دهد که کامپایلر نیاز به انجام تجزیه و تحلیل موردی ندارد. اگر برای مثال، تنها دستورالعمل نمنشعب شرطی مواردی می باشد که برای برابری و کمتر از آن تست می گردد، تنها یک راه برای ایجاد کد برای هر یک از این شش رابطه وجود دارد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

متناوبا، اگر فرایند اجرای مستقیمی از تمام این شش رابطه وجود داشته باشد، برنامه نویسی مشخصی برای هر یک از آن ها وجود دارد. مشکلات به هر حال زمانی ایجاد می شودکه تنها سه یا چهار مورد از این شش رابطه ایجاد گردد. برای نمونه، برنامه مترجم  (کامپایلر) می بایست تصمیم بگیرد که آیا با محاسبه دستور اجرایی، مراحل اجرایی کم هزینه تری از بعضی از روابط باقیمانده وجود دارد. متاسفانه این یک تصمیم گیری ساده نمی باشد- ممکن است به تعیین چنین موردی بپردازد که آیا نتیجه جانبی معانی نقص می گردد، آیا تعاملی با اختصاص موارد ثبتی با غیره وجود دارد.  هم اکنون اصول موارد مقدماتی ایجاد شده و نه راه حل را مد نظر قرار دهید. بر طبق نظر من، آنچه که تلاش صادقانه برای کمک به مولفان کامپایلر می باشد، بعضی از طراحان امروزی موارد اجرایی مستقیمی از مفاهم سطح بالا همانند دستورات FOR و CASE و رویکردها را ایجاد کرده اند.

در بسیاری از موارد، ولی نه تمام آن ها، دردسر بیشتری نسبت به مزایای آن وجود دارد. آن ها همواره یا تنها از یک زبان به خوبی پشتیبانی می کنند، یا آنقدر کلی می باشند که برای موارد خاص ناکارآمد است- بنابراین CASE را مجبور می کند تا تجزیه و تحلیل بیشتری را برای مد نظر قرار دادن موارد جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

- آدرس دهی. محاسبه ادرس بر مبنای مسیرها می باشد! ادرس دهی محدود به ارایه ساده و دسترسی به موارد ثبت شده نمی باشد!

روش ادرس دهی دستگاه به گونه ای طراحی می گردد که این حقایق را مشخص کند.

- پشتیبانی محیطی. تمام طرح های مدرن محاسبات منطقی و ریاضی را به طور معقولی انجام می دهند. آن ها همچنبن در پشتیبانی از محیط اجرا در ارتباط با قالب برنامه، نمایش یا لینک های ایستا/پویا، پیش بینی، مراحل و غیره نقش دارند. مولف می بایست پشتیبانی محیط اجرا را نیز انجام دهد.

- انحراف . مولف می بایست از این اصول به روشی که موارد اجرایی مستقل می باشند، اجتناب کند. اولین مورد از این دو اصل، یعنی ادرس دهی و پشتیبانی محیطی در بین سخت ترین موارد بوده- و همچنین در میان موارد احتمالی برای اجرای کامل اصول موارد مقدماتی و نه راه حل وجود دارند.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

یک طراح آگاه می بایست به خاطر داشته باشد که زبان های برنامه نویسی مختلف محدودیت های مختلفی را بر روی مفهوم رویکردها، فعالیت ها و انتظارات تحمیل می کنند. حتی مواردی که معمول بوده و دستورات تکراری و بازنمایی ارایه ها توسط معنا شناسی زبان برنامه نویسی نشان داده شده و از یک زبان به زبان دیگر متفاوت می باشد.

من موارد بیشتری را در ارتباط با این نکات بعدها بیان کرده، اما به من اجازه بدهید بعضی از این موضوعات را با مسئله ادرس دهی توضیح دهم. در تجارب من، کاربرد موثر ادرس دهی ناآشکار به عنوان یکی از مهمترین جنبه ایجاد کد معتبر می باشد. اغلب دسترسی به آن مشکل می باشد. به طور کلی، دستیابی به یک داده از ساختار اطلاعاتی شامل دنبال کردن مسیری می باشد که طول آن قراردادی می باشد ( اما در زمان کامپایل شناخته شده می باشد). هر گام به سمت این مسیر بر مبنای افزایش ( فهرست سازی به سمت ارایه ها و موارد ثبت شده) یا یک مسیر غیر مستقیم ( از طریق اشاره به طبقات مختلف) می باشد. کامپیوترهای معمولی یک فهرست محدود و ثابتی را ایجاد می کنند- که مجموعه ای از موارد خاص می باشد- که در ارتباط با چنین مسیری، بعضی از طراحان موارد اجرایی مستقیمی را در ارتباط با مفاهیم سطح بالا ایجاد می کنند. در بسیاری از موارد به نظر می رسد که دردسر بیشتری نسبت به ارزش آن وجود داشته باشد.

مراحل. مشکلات کامپایلر این می باشد که چگونه می توان به صورت کارآمدی در بین این فهرست ها انتخابی انجام داد؛ من هیچ تکنیکی را در مورد انجام این فرایند به جز تجزیه و تحلیل موارد خاص فراگیر نمی شناسم. حتی زمانی که روش های ادرس دهی کامپیوتر هدف، متناسب با اکثر موارد معمول می باشد، کامپایلر آن پیچیده بوده زیرا برای به اجرا در آوردن موارد کلی آماده می باشد. بنا به نظر من، اصل آخر از نقطه نظر ماهیت درخواست می باشد. جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. به نظر من بیشتر تخلفات از این مفاهیم همانند تعامد و قواعد به سمت موارد پیش بینی نشده هزینه ها پیش می رود. وفادار بودن به اصول هایی که در اینجا نشان داده شده است، اطمینان از هزینه های سخت افزاری قابل اندازه گیری می باشد اما مواردی نیز می بایست به صورت مشخص با تغییر فناوری کاهش یابد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

از نقطه نظر مولف کامپایلر،  تجهیزات مختلف دارای خصوصیات بد و خوب می باشند که به شرح یا تخلف اط اصول مورد نظر بالا می پردازد. این بدین معنی نمی باشد که به عنوان لیست جامع چنین خصوصیاتی مد نظر قرار گیرد، و همچنین به قفصد مورد انتقاد قرار دادن کامپیوترها یا سازندگان خاص نمی باشد. بر مبنای قوانین، به عنوان یک مولف کامپایلر، می بایست این روند را در بسیاری از تجهیزات اخیر مد نظر قرار دهم تا هر دستور اجرایی توسط یکی از روش های ادرس دهی مد نظر قرار گیرد. توانایی کامپایلر برای مد نظر قرار ددن حافظه و موارد ثبتی همچنین منبع و مقصد به طور متقارن نمونه عالی از مزایای قواعد می باشد. کامپایلر ساده تر بوده و کد مقصود بهتر می باشد. به هر حال، تمام جنبه های مربوط به تجهیزات مدرن به طور منظم طراحی نمی گردد. اکثر تجهیزات از چندین نوع اطلاعات ( شامل اشکال ممیز ثابت و شناور)، چندین نوع واژه ( ضرورتا بردارهای بولی) ، و چندین ادرس پشتیبانی می کنند- که اغلب هر کدام در چندین سایز بوده  که بر مبنای تغییراتی همانند موارد علامت دار یا بدون علامت و موارد معمول و غیر معمول می باشد. برای اپراتورهای از این دست نیز نادر می باشد تا به طور مشخص تعریف شده حتی زمانی که آن به صورت مفهومی برای آن ها باشد. برای مثال، یک کامپایلر تمایل دارد اعداد صحیح را بر مبنای ادرس یا بایت نشان دهد. با این وجود یک دستگاه مجموعه کاملی از بایت را ایجاد می کند. دستورالعمل های تغییر یافته محاسباتی نمونه دیگری از موارد نامتعارف می باشد.

عملیاتی که متقارن با عملیات واژه (اعداد صحیح) می باشد به جز بایت های ADD و SUB ناپیدات بوده و موارد دیگری به تعریف مجموعه کدهای شرطی می پردازد که نسبتا متفاوت از بایت های عملیاتی برای عملیات کلمه کامل می باشد. چنین تفاوتی از کامپایلرهای ساده برای استفاده از نمایش بایت های مشخص اجتناب می کنند. در ارتباط با کامپایلرهای مهمتر، تجزیه و تحلیل های مهمی می بایست انجام گیرد تا مشخص شود آیا تفاوت ها در برنامه خاص کامپایل می گردد.

دستورات مشخص تغییر مکان حسابی نمونه دیگری از این بی نظمی می باشد. من به هر کسی که درک می کند چنین تغییرات محاسباتی توسط توان دو منظوره در اکثر دستگاه ها تقسیم نمی گردد، اعتماد دارم.

تخلفات آزاردهنده مشخص از این موارد منظم، از دستورات دستگاه هایی که قوانین خاصی را برای روش بی واسطه محاسبات ایجاد می کنند، به وجود می آید. ما از تحلیل برنامه های منبع در میابیم که موارد ثابت مشخصی به ویژه 0, ± 1 و تعداد بایت در هر واژه به طور مستمر آشکار می گردد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

ایجاد مدیریت خاص برای این موارد در مجموعه دستورالعمل ها مفهومی می باشد. با این وجود به نظر می رسد که بسیاری از طراحان دستگاه ها احساس می کنند که چنین دستوراتی تنها در شکل دهی آدرس ها مفید بوده- یا حداقل آن ها دارای تاثیر مشابهی نسبت به موارد مشابه پرهزینه تر نمی باشند.

این آشکار سازی شامل موارد زیر می باشد

- کد وضعیتی که به چنین روشی آغاز نمی گردد

- رقم انتقالی که فراتر از اندازه یک ادرس منتشر نمی گردد، و

- عملیاتی که محدود به فعالیت در مجموعه منتخب ثبت فهرست می باشد.

در عمل، البته i = i+ 1 ( و مواترد مشترک اشاره شده در دستورات تکراری) به عنوان یکی از معمول ترین دستورات برنامه منبع می باشد. اختلالاتی همانند مواردی که در بالا مطرح شد، مانع کامپایلرهای ساده از استفاده روش محاسباتی بی واسطه برای چنین موارد معمول شده و پیچیدگی های بیشتری را نسبت به کامپایلرهای مشخص تر ایجاد می کند. نکات مشابهی در ارتباط با دستورالعمل هیا ممیز شناور بسیاری از دستگاه ها وجود دارد. علاوه بر ایجاد مجموعه محدودتری از عملیات، این دستگاه ها اغلب از پشتیبانی موارد مجزا ارقام واقعی که مد نظر بسیاری از زبان های برنامه نویسی سطح بالا می باشد، اجتناب می کنند. جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. به بکارگیری بعضی از موارد بهینه آشکار می باشد. هزینه بر مبنای پیچیدگی فزاینده کامپایلرو کندی برنامه ها می باشد. و چیز مایوس کننده این می باشد که مواردی که بهینه سازی غیرقانونی می باشددر عمل کمیاب می باشد. با بیان تعامد، منظور من توانایی برای تعریف موضوعات مجزا – همانند ادرس دهی، عملیات و اطلاعات از نوع مجزا می باشد. این خصوصیت دقیقا همراه با موارد مقررات و قابلیت ساخت می باشد. نقص دستگاه های ثبت کلی بر مد نظر قرار دادن تمام موارد ثبت شده بر مبنای نقص هر یک از این خصوصیات مد نظر قرار می گیرد. چندین دستگاه شامل اشکال بلند و کوتاه دستورالعمل های انشعابی می باشد، برای نمونه شکل کوتاه آن بر مبنای جا به جایی ثابتی نسبت به شمارشگر برنامه بوده و روش ادرس دهی می باشد که در دستورهای نوع دیگر موجود نمی باشد. بعضی از دستگاه ها شامل دستوراتی می باشند که که تاثیر آن ها بستگی به روش ادرس دهی مورد استفاده دارد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

برای نمونه، در ارتباط با بعضی از دستگاه ها، گسترش علامت انجام می گیرد که وابسته به محل مقصد می باشد. دستگاه های دیگرمجموعه ای از نتایج کوتاه مدت یا بلند مدتی را در نتیجه بس شماری ایجاد می کنند که بستگی به موارد غیرمعمول ثبت مقصد دارد. بعضی ازمحبوب ترین دستگاه ها شامل مجموعه دستورالعمل های متفاوتی برای ثبت رجیستر، ثبت حافظه، و عملیات حافظه در حافظه می باشند ( و بذتر اینکه این مجموعه دستورالعمل ها تا اندازه ای- و نه به صورت کامل- ادغام می گردند. همچنین باید مشخص شود که کامپایلر می بایست به تجزیه و تحلیل مجزا برای هر یک از این موارد بپردازد. و بر خلاف بعضی از نمونه های قبلی، این شرایط می بایست برای کامپایلرهای مهم و ساده به کار گرفته شود. بر اساس قابلیت ساخت. از نقطه نظر مولف کامپایلر، یک دستگاه ایده آل، در بین تمام موارد، حاصلضرب برداری کامل عملیات را در دسترس قرار داده و روش ها را در ارتباط با انواع داده های مشابه مد نظر قرار می دهد. دستور ADD دارای نتاثیر مشابهی می باشد اگر لفظ، بایت یا برای نمونه واژه ای را اضافه کند. علاوه بر این روش ادرس دهی موجود در یک متغیر می بایست در موارد دیگر نیز در دسترس باشد.

ارتباط بیشتر در مورد اهداف کنونی، مفهوم تغییر می باشد. بسیاری از دستگاه ها در این مورد به شدت دچار نقص می گردند ( یعنی دستورات منشعب شرطی) که روند کنترل را تحت تاثیر قرار داده در حالی که زبان های برنامه نویسی منبع معمولا اجازه می دهند که عبارات نسبی در شرایطی آشکار می گردند که ارزش بولی نیز آشکار گردد ( برای مثال، این امکان را به آن ها می دهد تا در متغیر بولی کاربر ذخیره گردد). علاوه بر این بسیاری از دستگاه ها تغییری را بین انواع اطلاعاتی همانند عدد صحیح و ممیز شناور ایجاد نکرده، و همچنین تغییراتی را که متفاوت از موارد مشخص شده در زبان برنامه نویسی منبع می باشد، ایجاد نمی کنند.

ریشه این مشکل در این حقیقت می باشد که زبان های برنامه نویسی انواع را بر مبنای خصوصیات اطلاعات ( متغیرها) در نظر گرفته، در حالی که دستگاه ها این انواع را به عنوان ویژگی اپراتورها در نظر می گیرند. چون تعداد انواع داده های ماشینی نسبتا زیاد می باشد، تعداد کدهای عملیاتی که برای به اجرا در آوردن ضرب برداری مورد نیاز می باشند، نامعقول می باشد. برای نمونه معمولا غیرممکن می باشد تا بایتی را به یک واژه بدون تبدیل اولیه بایت به شکل واژه کامل اضافه کنیم. نیاز برای چنین تغییرات مشخصی این منشکل را به وجود می آورد تا مشخص کنیم چه زمانی هزینه کلی با انتخاب موارد معرفی شده خاص کاهش می یابند. مسلما در جایی که این تغییرات مهم می باشد ( همانند تغییر عدد صحیح به ممیز شناور)، این مورد نقص نمی باشد بلکه پیچیدگی را به کامپایلر اضافه کرده و همچنین فرایند کامپایل و اجرا را در موارد جزئی کمتر می کند.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

من این بحث را با نمونه ای از پیچیدگی تحمیل شده بر روی کامپایلر به دنبال نبود فاعده، تعامد و قابلیت ساخت به پایان می رسانم. یک دستور ساده همانند A: = B*C  را در نظر بگیرید و تصور کنید ما به کامپایل یک ماشین که بر روی ان دستور اجرایی ضرب می بایست در یک مورد ثبتی غیرمعمول باشدانجام می دهیم. یک کامپایلر ساده معمولا موارد ثبتی را به دنبال ایجاد کد مد نظر قرار می دهد. در این مثال، به نظر می رسد که این استراتژی به خوبی کار کند؛ موارد اختصاص داده شده تنها نیازمند پیچیدگی جزئی می باشد تا در ارتباط با موارد ثبت شده غیرمعمول شاختی را به دست آورده و مولد کد می بایست به تعیین نیاز در ارتباط با هر درخواست بپردازد. اما در فرمول های نسبتا پیچیده تر همانند A = (B + D)*C ، این استراتژی فرو می ریزد. موارد دیگری نیز در ارتباط با موارد ثبتی غیرمتعارف و هم سطح انجام می گیرد؛ موارد تخصیص داده شده مستمر احتمالا موارد ثبت شده را به عنوان مورد نامتعارفی برای B + D در نظر گرفته، البته انتخاب موارد هم سطح نیازمند جا به جایی اطلاعات مازاد برای ضرب کردن با c می باشد. کامپایلرهای مهمتر به تحلیل معادله فرمان tree کامل قبل از ایجاد تخصیص می باشند. در فرمان tree که شامل شرایط متضاد می باشد، نقل و انتقالی انجام می گیرد که جا به جایی اطلاعات را به حداقل می رساند.

کامپایلرهای مهمتر ممکن است دارای مشکلاتی با موارد انتقالی ساده باشند. A: + B*C. این کامپایلرها اغلب موارد تکنیکی به نام حرکت بارگذاری/ ذخیره را به کار می گیرند که تلاشی را به منظور جابه جایی دسترسی متغیرها به طور مستمر در بخش برنامه به سمتجهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.  این مورد به حذف موارد بارگذاری شده و ذخیره سازی شده منجر می گردد. موارد ساده بالا نشان می دهد که داشتن مورد اختصاصی A در ارتباط با موارد ثبت شده غیرمتعارف مناسب بوده، از این رو کل موارد کمکی در A ارزیابی شده و جابه جایی اطلاعاتی دیگر کنار گذاشته می شود.

اگر این موارد مطلوب باشد، به هر حال بستگی به موارد دیگری از کاربرد A در بخش برنامه تحت موارد ثبت شده ای که A بر مبنای آن قرار دارد، می باشد. این شامل تجزیه و تحلیل پیچیده تری از موردی که برای معادله ساده تر وجود دارد، می باشد و مجدادا نیازمند سبک و سنگین کردن تعداد اطلاعات جا به جا شده مورد نیاز می باشد.

توجه داشته باشید که این پیچیدگی ها در شرایط دیگر علاوه بر موارد ثبت شده غیر متعارف و همسان ایجاد می گردد. حداقل یک ماشین دارای اکومولاتور و شاخص های ثبت شده مجزا علاوه بر چند عنصری که به این صورت مورد استفاده قرار می گیرد، می باشد. دقیقا مشکلات کامپایلر مشابهی در ارتباط با این تصمیم گیری ایجاد می گردد که نتیجه مربوط به دستورالعمل حسابی یا متغیر کاربر به چه جاهایی می رود. کامپایلر می بایست به بررسی تمام موارد کاربردی بپردازد تا مشخص شود ایا این نتایج در شرایط فهرست سازی، شرایط محاسباتی و یا هر دو بکار گرفته می شود.

ص 12

یکی در برابر همه.مطمئن هستم که اکثر خوانندگان که با ارقام ماشین ها آگاهی دارند می توانند نمونه هایی را در ارتباط با نقص این اصول ارائه دهند. موارد مورد نظر من در یکی از جدید ترین دستگاه ها با مجموعه دستورالعمل ها یافت می گردد. این مجموعه به طور منطقی شامل عملیات بولی کامل بوده اما AND را ایجاد نکرده و در عوض AND NOT را مد نظر قرار می دهد. AND به صورت جا به جایی پذیر و مرتبط بوده اما AND NOT به این صورت نمی باشد. بنابراین نیازمند تجزیه و تحلیل پیچیده ای در ارتباط با تعیین این مورد می باشد که چه دستور اجرایی را می بایست تکمیل کرده و اینکه در چه زمانی قانون DeMorgan را به منظور ایجاد یک توالی کد بهینه بمار بگیریم.

موارد مقدماتی در برابر راه حل. بیشتر افراد براین عقیده می باشند که زبان برنامه نویسی پاسکال قوی تر از زبان فرترن می باشد. معنای دقیق " قوی تر" کمی نامشخص می باشد، اما مطمئنا هر الگوریتمی که می تواند در فرترن کد گذاری شود همچنین می تواند در زبان پاسکال نیز کد گذاری شود- اما برعکس این مورد وجود ندارد. به هر حال این بدین معنی نمی باشد که این مورد آسان و یا محتمل می باشد که به ترجمه برنامه های فرترن درون زبان برنامه نویسی پاسکال بپردازیم. خصوصیاتی همانند ماشینی که تلاشی را به منظور پشتیبانی تمام موارد اجرایی مورد نیاز انجام می دهد، احتمالا مانع پشتیبانی از آن ها به طور کارآمد می گردد.

موارد معمولجهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. بسیار متفاوتی را از مفاهیم ضرورتا مشابه دریافت می کند. معانی مفصل مرتبط به گذر پارامتر، دستوراات FOR، تغییرات، و موارد دیگر اغلب موارد کاملا متفاوت می باشد. این تفاوت ها می تواند منتهی به شرایط اجرایی کاملا متفاوتی گردد. ماشینی که در آن دستورات داخلی به تعیین مجموعه ای از این شرایط می پردازد، نمی تواند زبان های برنامه نویسی دیگر را پشتیبانی کند. دستگاهی که به پشتیبانی تمام شرایط می پردازد احتمالا به پشتیانی تمام این موارد نپرداخته- و از این رو تجزیه و تحلیل های خاص دیگری را در کامپایلر بر می انگیزد. نمونه هایی از موارد جا به جا شده طراحان ماشینی شامل

- دستورات فراخوانی زیرروال می باشد که برای نمونه تنها به پشتیبانی بعضی از پارامترهای مکانیسم گذرا می پردازد.

- دستورات ایجاد حلقه که تنها مدل خاصی از فرمت، تست و موارد افزوده، و محاسبه مجدد را پشتیبانی می کند.

- مد نظر قرار دادن روش هایی که شامل طرح چارچوب خاص بوده- یا مجموعه های خاصی را مد نظر قرار می دهد.

- دستورهای موردی که که به طور آشکار و غیرآشکاری به بررسی شرایط حدی فهرست موردی پرداخته و این فرضیات را مد نظر و خارج نظر قرار می دهد که چنین محدوده ای در زمان کامپایل ایستا می باشد.

- دستورهایی که به پشتیبانی از ساختار اطلاعاتی سطح بالا ( همانند کویز) پرداخته و فرضیاتی را انجام می دهند که متفاوت از بعضی موارد اجرایی معمول در ارتباط با این ساختارها می باشد، و

- شرح دستکاری رشته ای

در بسیاری جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

در ارتباط با ادرس دهی. زبان برنامه نویسی پیشرفته امکان تعریف ساختار اطلاعاتی را ایجاد می کند که به طور قراردادی متشکل از مقیاس ها، آرایه ها، موارد ثبتی و اشاره گرها می باشد. حداقل در اصول این امکان وجود دارد تا به تعریف مجموعه موارد ثبت شده بپردازیم که بخشی از آن بر مبنای اشاره گرهایی برای ثبت مجموعه ای از ارایه ها و ارایه های ی از نوع دیگر می باشد. دسترسی به بخش های سطح پایین این ساختار شامل مجموعه طویلی از عملیات می باشد. علاوه بر این به دلیل تعامل بین ساختار بلوکی، روش های بازگشتی ، و به اصطلاح گذر از پارامترها، یافتن ادرس مبنای چنین ساختاری پیچیده می باشد که احتمالا شامل فهرست سازی از طریق نمایش ، و انواع مختلف اطلاعات ( واصف) و چندین سطح غیرمستقیم از طریق ارزش های پارامتر مورد اشاره می باشد. البته در عمل ساختارهای اطلاعاتی به ندرت دارای این پیچیدگی می باشند و. اکثر متغیرهای دردسترس یا در ارتباط با رویکردهای کنونی به صورت محلی بوده یا در ارتباط با کل برنامه سراسری می باشند. و به طور قابل توجهی، ساختارهای نسبتا ساده همانند دسترسی به مجموعه عوامل در این چارچوب کنونی ممنجر به افزایش این پیچیدگی ها می گردد.

الگوریتم برای دسترسی به عوامل ساختار اطلاعاتی همانند عبور یک مسیر از موارد ثبت شده جاری نسبت به عوامل می باشد؛

بخش اول این مسیر، به تعیین مسیر ادرس ساختاراز طریق موارد نشان داده شده و غیره گشته و بخش نهایی توسط خود ساختار تعریف می گردد. هر مرحله از این مسیر شامل موارد غیر مستقیمی می باشد ( به دنبال اشاره گر)، که به محاسبه جا به جایی عوامل ثبت شده یا فهرست بندی می پردازد ( توسط یک زیر نویس مشخص)- که تمام آن ها شامل ضرب کردن زیرنگاشت با اندازه ( در واحدهای ادرس)  بخش ارایه می باشد. در ارتباط با بسیاری از زبان های برنامه نویسی ، محدودیت ها بر روی مجموعه زیرنگاشت بررسی شده و اشاره گر ها می بایست در طول مسیر به اجرا گذاشته شوند.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

- یکی از محبوب ترین ماشین ها اصلا هیچ مسیر غیر مستقیمی نداشته، بنابراین با مجبور کردن یک دستور مشخص در هر زمان، یک اشاره گر مد نظر قرار می گیرد.

- اکثر ماشین هایی که فهرست سازی کرده و یا موارد غیر مستقیمی را ایجاد می کنند به تعریف یک دستور ثابت می پردازند. – برای نمونه ایتدا فهرست بندی انجام می شود، سپس مسیر غیرمستقیم دنبال می شود، اگرچه موارد متضاد در فعالیت ها معمول می باشد.

- بعضی از دستگاه های پیشرفته شمارش ضمنی از دستور اجرایی عملیات فهرست سازی را فراهم می کنند، اما تنها با در نظر گرفتن مقیاس ها این امر امکان پذیر می باشد ( به صورتی که در کل عوامل مربوط به این ارایه ها به صورت مدرج نمی باشد)؛ و

بسیاری از ماشین ها به محدودسازی ارزش واقعی در روش فهرست سازی پرداخته و به این ترتیب کدهای کنترلی را وادار به جا به جایی بیشتر و یا در مواردی که  جا به جایی شناخته شده نمی باشد تا زمان ارتباط، می کند.

روش های ادرس دهی برای بعضی از موارد و نه تمام آن ها مفید می باشد. بدتر اینکه گاهی اوقات بیش از یک روش مورد استفاده قرار گرفته و کامپایلر می بایست انتخاب های غیربدیهی انجام دهد. بار دیگر، کامپایلر می بایست پیچیده تر گردد تا سخت افزارها به کار گرفته شود. همچنین بهتر ( و از نقطه نظر سخت افزاری ساده تر) می باشدتا مدل کلی تر و مناسب تری را مد نظر قرار دهیم.

در ارتباط با محیط. من براین نظر می باشم که امروزه اکثر افراد قدر  پشتیبانی سخت افزاری را در ارتباط با رویکرد های بازگشتی، تخصیص حافظه پویا ، و هماهنگ سازی و مراحل ارتباطی می دانند.

ص 15

من توضیحی در این ارتباط نمی دهم مگر اینکه خطر ایجاد چنین پشتیبانی در سطح بالایی بوده و همچنین به معرفی برخورد معنایی با بعضی از زبان های برناممه نویسی می پردازم. در عوض، من بعضی از موارد نادیده گرفته شده محیط پشتیبانی را اشره می کنم که منجر به تحریک موارد بالاسری در بکارگیری حداقل بعضی از زبان های برنامه نویسی می گردد. این موارد شامل:

- متغیرهایی بدون مقدار اولیه. بسیاری از زبان های برنامه نویسی زمانی نادرست بودن برنامه را تعریف می کنند که ارزش متغیر قبل از تنظیم شدن، مد نظرقرار گیرد. ساختارهای کد و اطلاعات که به پشتیبانی این موارد می پردازند، هزینه بردار می باشند. با این وجود حداقل یک دستگاه قدیمی روشی را برای کنترل این موارد به صورت رایگان با تنظیم بیت های خطا بر روی متغیرهای بدون مقدار اولیه می پردازد.

- بررسی محدودیت. بسیاری از زبان های برنامه نویسی به تعیین چنین موردی می پردازند که ویژگی های خاصی از یک مقدار قبل از استفاده چک گردد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

- موارد استثنا.  موارد استثنا ( که مشابه شرایط PL/I's می باشند) بخشی از بسیاری از زبان های برنامه نویسی می باشمند. با این وجود دستگاهای کمی از آن ها پشتیبانی می کند، و اجرای نرم افزار کارامد آن هااغلب موارد فرضیه پشتیبانی سخت افزار را که در ارتباط با رویکردها می باشد، نقض می کند.

- پشتیبانی از مشکل زدایی. اگر بیشتر برنامه نویسی ها در زبان های برنامه نویسی سطح بالا انجام گیرد، به این ترتیب بدیهی می باشد که اشکال زدایی می بایست در سطح مشابهی باشد. چون اکثر دستگاه ها به پشتیبانی این مورد نمی پردازند، به هر حال طراحان سیستم اشکال زدایی معمولا با دو انتخاب روبرو می باشند که هر دو غیر مطبوع می باشند. اولین مورد اجبار کاربر برای اشکال زدایی در سطح پایین می باشد. دومین مورد ایجاد روش اشکل زدایی خاصی می باشد که کدهای مازاد اشکال یابی را در حال اجرا با اطلاعات مورد نظر انجام می دهند- این مورد در عوض اشکال زدایی نسخه تولیدی سیستم را مشکل می سازد.

نکته هایی در ارتباط با بخش ذخیره اطلاعات.اعتقاد مشترک بر این است که تمام مولفان کامپایلر یک دستگاه ذخیره کننده اطلاعات را ترجیح می دهند. من استثنائی نسبت به این نظرات می باشم- حداقل تا انجایی که در ارتباط با ارزیابی معادلات مربوط به بخش ذخیره اطلاعات می باشد. ( بخش ذخیره کننده اطلاعات که به پشتیبانی محیز می پردازد موضوع متفاوتی می باشد. مطمئنا صحیح می باشد که مسیردهی جزئی از فرمان تجزیه trees تا پسوند آن وجود داشته، و از این رو کامپایلرهای ساده می توانند ساده تر گردند اگر اهداف مربوط به آن ها دارای بخش ذخیره سازی باشد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

در ارتباط با کامپایلرهای مهمتر، به هر حال دستگاه های ذخیره کننده تقریبا تمام مشکلات بهینه سازی مشابه را به عنوان دستگاه های ثبت کننده مد نظر قرار می دهند. یک معادله فرعی معمولی هنوز هم یک معادله فرعی می باشد. یک حلقه تغییر ناپذیر هم همچنان تغییر ناپذیر باقی می ماند. معادلات سازمان دهی شده بر روی دستگاه ثبت کننده انجام می گیرد تا تعداد موارد ثبت شده مورد استفاده را به حداقل برساند، که همچنین باعث کاهش عمق ارزیابی بخش ذخیره سازی شده- و بنابراین باعث افزایش احتمالاتی می گردد که کل محاسبه در موارد ثبت شده سریع در بالیا این مجموعه ذخایر قرار می گیرد.

حتی اختصاص موارد ثبت شده دارای همتایی می باشد- یعنی، اختصاص متغیرها به جارچوب بخش ذخایر به گونه ای که اکثر موارد دسترسی از شکل ادرس دهی کوتاه بر روی دستگاهی که چنین خصوصیاتی را ایجاد می کند، استفاده می کند. علاوه بر این تصمیم گیری در این ارتباط که  آیا بهینه سازی مطلوب می باشد بر روی دستگاه های ذخیره کننده پیچیده تر می باشد. در ارتباط با دستگاه های ثبت کننده، برای نمونه، تقریبا همیشه منطقی می باشد تا مقادیر معادله فرعی را ثبت کنیم. در حالی که در ارتباط با دستگاه های ذخیره کننده ضروری می باشد که به تعیین این مورد بپردازیم که آیا هزینه افزوده ذخیره سازی و بازیابی مقدار توسط کاربرد مقادیر جبران می گردد. بنابراین در حالی که این مجموعه ذخیره شده برای کامپایلرهای ساده مناسب می باشد، آن ها به هیچ وجه راه حل نمی باشند.

نکته ای در ارتباط با مفسر و دستورالعمل های ریز نوشتنی. یک رویکرد محبوب فزاینده ، بهه ویژه در زمینه ریزپردازنده، بر مبنای برنامه ریزی تفسیر با هدف خاص برای زبان برنامه نویسی منبع مورد نظر می باشد. برای نمونه چنین مواردی به طور گسترده برای زبان برنامه نویسی پاسکال به اجرا در آمده است. همان طور که در بالا نشان داده شده است، در کل من موارد اولیه و نه راه حل را ترجیح می دهم ( به ویژه راه حل اشتباه)؛ سازماندهی مجموعه دستورالعمل ها از طریق ریزبرنامه نویسی روشی برای دستیابی به آن می باشد.

به هر حال مشکلاتی در ارتباط با این رویکرد وجود دارد. این نشان می دهد که جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. صحیح با مراحل داده شده برقرار کنیم. و این منجر به تغییر شرایط بالاسری  می گردد مگر اینکه فرد خیلی دقیق باشد. ( من در اینجا فرضیه ای را مد نظر قرار می دهم, من بر این عقیده می باشم که عملکرد چند برنامه ای، پردازش چندگانه، و پشتیبانی تماما در دنیای ریزپردازنده معمول می باشند- به ویژه در اشکالی که حاصل آنچه که ما در سیستم های بزرگ کنونی مشاهده می کنیم، می باشد.

ص 17

من همچنین بر این عقیده می باشم که سیستم مجزای زبان برنامه نویسی یک راه حل نمی باشد؛ ما می بایست محیط چندزبانی را مد نظر قرار دهیم. دلایلم در ارتباط با این عقاید برای این مقاله مناسب نمی باشد، اما چندین اعلامیه از چندین سازنده تراشه همگام با نظر من می باشد.

فراتر از همه، این رویکرد یک راه علاج نمی باشد! حداقل در یک موردی که من بررسی کردم، کدهای ایجاد شده برای چنین تفسیری دقیقا با دو برابر سرعت کمتر بوده و بزرگتر از آنچه باید باشد است. در مورد بعدی، یک کامپایلر بهینه شده پیچیده می بایست ایجاد گردد تا عملکرد معقولی حاصل گردد. مولفان کامپایلرو طراحان دستگاه دارای اهداف چندگانه ای می باشند. طراحان دستگاه می بایست مطمئنا در ارتباط با اجرای زبان برنامه نویسی سطح بالا موضوعاتی را مد نظر قرار دهند- جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید. از این اهداف را در هر سمت تحت تاثیر قرار دهند. به هر حال، آن ها همچنین می دانند که آن ها می توانند فعالیت های زیادی برای بهبود انطباق بین زبان های برنامه نویسی و دستگاه ها انجام داده و همچنین هزینه های کلی را کاهش دهند.

اسپانسر این تحقیق سازمان پروژه تحقیق دفاعی پیشرفته بوده و تحت نظارت بخش ارتباطات فضایی نیروی هوایی می باشد. نظرات و نتیجه گیری موجود در این مقاله در اختیار محقق بوده ونمی بایست به دلیل سیاست های رسمی، چه به صورت کاربردی یا تشریحی در ارتباط با سازمان پروژه تحقیق دفاعی پیشرفته یا دولت ایالات متحده ارائه گردد.

جهت مشاهده متن کامل، فایل ترجمه را دانلود نمایید.

William A. Wulf پروفسور علوم کامپیوتر در دانشگاه Carnegie-Mellon می باشد. قبل از پیوستن به CMU در سال 1968، او استاد ریاضیات کاربردی علوم کامپیوتر در دانشگاه ویرجینیا بوده است. ارتباط تحقیق او در محدوده ای می باشد که به طور سنتی به نام سیستم برنامه نویسی و معماری کامپیوتر می باشد. او همچنین علاقمند به ساخت سیستم های بزرگتر، به ویژه کامپایلرها و سیستم های عامل می باشد و به این ترتیب ایجاد چنین سیستم هایی در تعامل با طرح دستگاه هایی می باشد که آن ها به اجرا در می آیند. فعالیت های تحقیقی Wulf شامل طراحی و اجرای زبان برنامه نویسی سیستم Bliss، مشارکت در طرح PDP-1، ساخت C.mmp- - یک کامپیوتر 16 پردازنده ای، طراحی و اجرای سیستم عامل Hydra، برای C.mnp ، طراحی زبان برنامه نویسی Alphard ، و مشارکت در ایجاد Ada، و زبان برنامه نویسی DoD برای برنامه های کاربردی مرتبط به کامپیوتر  می باشد. Wulf مدرک لیسانس خود را در رشته فیزیک و فوق و لیسانس خود را از دانشگاه Illinois گرفته و مدرک دکترا خود را از دانشگاه ویرجینیا در جولای 1981 گرفت.