مشین کوڈ اور بائٹ کوڈ: آپ کا پروگرام کون سی زبان بولتا ہے؟

جو لوگ ابھی جاوا سے واقف ہونا شروع کر رہے ہیں وہ اکثر مشین کوڈ اور بائٹ کوڈ کے تصورات کے بارے میں الجھن کا شکار ہوتے ہیں ۔ وہ کیا ہیں؟ اختلافات کیا ہیں؟ ایک مختصر نوٹ میں، ہم اس مسئلے کو ایک بار اور ہمیشہ کے لیے بند کرنے کے لیے ان کی خصوصیات کو ہر ممکن حد تک آسان اور واضح طور پر بیان کرنے کی کوشش کریں گے۔

مشین کوڈ

پروسیسر ، جوہر میں، ایک بہت پیچیدہ اور جدید کیلکولیٹر ہے۔ اس میں میموری کے بہت سے مقامات ہیں (جسے رجسٹر کہتے ہیں) اور ان کے درمیان مختلف ریاضیاتی اور بائٹ آپریشنز کیے جاتے ہیں۔ مشین کوڈ بالکل درست طور پر کارروائیوں کی ترتیب اور اس میں شامل ڈیٹا کے سیٹ کی تفصیل ہے۔ درحقیقت، یہ واحد زبان ہے جسے آپ کے کمپیوٹر کا پروسیسر سمجھتا ہے۔

پیدائشی عدم مطابقت

مزید یہ کہ تمام پروسیسرز ایک ہی زبان "بولتے" نہیں ہیں۔ نہ صرف CISC اور RISC فن تعمیر کے درمیان ، بلکہ ان "کیمپوں" کے اندر بھی فرق ہے ۔ پروسیسرز کی نئی نسلیں ہدایات کے اضافی سیٹ متعارف کراتی ہیں جو پرانے نسل کے ماڈلز کے لیے بالکل نامعلوم ہیں۔ اس کی وجہ سے، ایک فن تعمیر (یا پروسیسرز کی ایک نسل) کے لیے مرتب کیے گئے پروگرام دوسرے ہارڈ ویئر پر نہیں چل سکتے۔ یہ سب ہمیں پروگراموں کو دوبارہ مرتب کرنے پر مجبور کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ وہ دوسرے کمپیوٹرز پر کام کرتے ہیں۔ تاہم، آپ کو نہ صرف پروسیسرز کی وجہ سے بلکہ پروگراموں اور آپریٹنگ سسٹم کے باہمی تعامل میں فرق کی وجہ سے بھی دوبارہ مرتب کرنا ہوگا۔ یہ ان کی وجہ سے ہے کہ لینکس کے تحت "ونڈوز" پروگرام اور ونڈوز کے تحت "لینکس" پروگرام چلانا ناممکن ہے۔

بائٹ کوڈ

بائٹ کوڈ بہت سے طریقوں سے مشین کوڈ سے ملتا جلتا ہے، صرف یہ ایک حقیقی پروسیسر سے نہیں بلکہ ورچوئل سے ہدایات کا ایک سیٹ استعمال کرتا ہے۔ مزید برآں، اس میں JIT کمپائلر کے استعمال پر توجہ مرکوز کرنے والے حصے شامل ہو سکتے ہیں ، جو حقیقی پروسیسر کے لیے کمانڈز کے عمل کو بہتر بناتا ہے جس پر پروگرام چل رہا ہے۔ CISC پروسیسرز کے لیے ، کچھ ہدایات کو پروسیسر کے تعاون سے زیادہ پیچیدہ ڈھانچے میں ملایا جا سکتا ہے، اور RISC کے لیے ، اس کے برعکس، انہیں ہدایات کے آسان سلسلے میں تقسیم کیا جا سکتا ہے۔

ایک ورچوئل OS بھی

تاہم، بائٹ کوڈ میں نہ صرف پروسیسر کی ہدایات ہوتی ہیں۔ اس میں ورچوئل آپریٹنگ سسٹم کے ساتھ تعامل کے لیے منطق بھی شامل ہے، جو ایپلی کیشن کے رویے کو کمپیوٹر پر استعمال کیے جانے والے آپریٹنگ سسٹم سے آزاد بناتی ہے۔ یہ JVM میں واضح طور پر نظر آتا ہے ، جہاں سسٹم کالز کے ساتھ کام کرنا اور GUI اکثر اس OS سے آزاد ہوتے ہیں جس پر پروگرام چل رہا ہے۔ مجموعی طور پر، JVM ایک پروگرام کے عمل کے آغاز کی تقلید کرتا ہے، ورچوئل باکس جیسے حل کے برعکس ، جو صرف ایک ورچوئل سسٹم/ہارڈ ویئر بناتے ہیں۔

کیا JVM صرف اس طرح ہے؟

یقینا نہیں. یہی DotNet CLI ایک ورچوئل مشین بھی ہے، جو اکثر X86 کمپیٹیبل پروسیسرز کے ساتھ ونڈوز چلانے والے کمپیوٹرز پر استعمال ہوتی ہے۔ تاہم، دوسرے سسٹمز کے لیے اس کا نفاذ موجود ہے: اس کے لیے ایپلی کیشنز کو ARM (RISC) کے موافق پروسیسرز پر چلنے والے Windows RT پر چلنا چاہیے، یا آپ انہیں Mono ماحول میں Linux/OSX پر چلا سکتے ہیں ، جو کہ ایک فریق ثالث ہے (اور اس لیے مکمل طور پر مطابقت نہیں رکھتا) ان پلیٹ فارمز کے لیے ڈاٹ نیٹ کا نفاذ۔ لہذا یہ پلیٹ فارم، JVM کی طرح ، مختلف پروسیسرز اور مختلف OS پر چلتا ہے۔ اسی طرح کے اور بہت سے حل ہیں (پرانے اور نئے دونوں): LLVM ، Flash SWF ، اور دیگر۔ کچھ پروگرامنگ زبانوں کی اپنی ورچوئل مشینیں ہوتی ہیں۔ مثال کے طور پر، CPython PY ذرائع کو PYC فائلوں میں مرتب کرتا ہے - مرتب کردہ بائٹ کوڈ جو PVM میں چلنے کے لیے تیار ہے ۔ یا ایک بہت پرانی مثال ہے - Lisp کو FASL (فاسٹ لوڈ) فائلوں میں مرتب کیا جا سکتا ہے ۔ درحقیقت، ان میں ایک AST درخت ہوتا ہے جو ماخذ کوڈ سے جنریٹر نے بنایا تھا۔ ان فائلوں کو مختلف پلیٹ فارمز پر Lisp ترجمان کے ذریعے پڑھا اور عمل میں لایا جا سکتا ہے ، یا فی الحال استعمال شدہ ہارڈویئر فن تعمیر کے لیے مشین کوڈ بنانے کے لیے استعمال کیا جا سکتا ہے۔