একটি প্রোগ্রামের 64 বিট সংস্করণ তৈরি করা কেন কঠিন হতে পারে?


29

আমার স্বল্প সময়ের প্রোগ্রামিংয়ে, আমার কাছে সি ++, জাভা ইত্যাদি যে কোনও একটি 32 বা 64 বিট মেশিনের জন্য এতক্ষণ পর্যন্ত সংকলন করা তুচ্ছ হয়েছে যতক্ষণ না আমার কাছে প্রোগ্রামটির পুরো উত্স রয়েছে।

তবে প্রচুর সফ্টওয়্যার 64 বিট প্রকাশিত হয় না। সবচেয়ে বিরক্তিজনকভাবে, এখনও ইউনিটি ইঞ্জিনের একটি 64 বিট প্রকাশ হয়নি।

Bit৪ বিট মেশিনের জন্য কিছু প্রোগ্রাম সংকলন করা কি কঠিন করে তোলে?


57
কারণ নির্বোধ প্রোগ্রামাররা ধরেই রাখেsizeof(int)==sizeof(void*)
রাচেট ফ্রিক

16
আমাদের পরিবেশের শীর্ষতম কারণটি হ'ল কিছু তৃতীয় পক্ষের উপাদানগুলির উপর নির্ভরতা যা 64৪ বিট হিসাবে উপলব্ধ নয়। এটিও ইউনিটির ক্ষেত্রে প্রযোজ্য কিনা তা জানেন না, তবে বিষয়টি যদি হয় তবে আমি খুব অবাক হই না।
ডক ব্রাউন

তারা টাইপডেফ যেমন int32, int64 এর জন্য int64, ভাসমান, পয়েন্টার পরিবর্তে তাদের আকার ধরে না ব্যবহার করতে পারে। যা অনেক সমস্যার সমাধান করতে পারে। আমরা ধরে নেওয়া শুরু করার সময় থেকেই অনেকগুলি সমস্যা শুরু হয়।
ক্ষিতিজ

প্রকৃতপক্ষে ফ্ল্যাট আর্কিটেকচারের ক্ষেত্রে এটি পুরোপুরি যুক্তিসঙ্গত অনুমান। উইন্ডোজ তাদের নিজস্ব স্ক্রু-আপগুলি না ভাঙতে ইচ্ছাকৃতভাবে এটি ভুল করেছে।
জোশুয়া

3
কেন এটি একটি যুক্তিসঙ্গত অনুমান হবে? আমি এর operator*জন্য একটি শালীন আশা করব int, তবে পয়েন্টারগুলির এটির প্রয়োজন নেই। এছাড়াও, বেশিরভাগ লিনাক্স এবং ইউনিক্স পরিবেশে int32 বিটও রয়েছে।
এমসাল্টারস

উত্তর:


61

সাধারণ সমস্যাটি হ'ল কোনও প্রোগ্রামে নথিভুক্ত অনুমানগুলি এনকোড করা খুব সহজ এবং সেই অনুমানগুলি করা হয়েছিল এমন জায়গা খুঁজে পাওয়া খুব শক্ত hard উচ্চ-স্তরের ভাষাগুলি আমাদের এই উদ্বেগগুলি থেকে কিছুটা অন্তর সঞ্চারিত করে, তবে প্ল্যাটফর্ম এবং পরিষেবাদি বাস্তবায়নের জন্য ব্যবহৃত নিম্ন-স্তরের ভাষাগুলিতে, এমন কাজগুলি করা সহজ যা আর্কিটেকচার জুড়ে প্রয়োজনীয়ভাবে বহনযোগ্য নয়:

  • ধরে নিচ্ছি যে intএটি পয়েন্টার সঞ্চয় করার জন্য যথেষ্ট বড়

  • পয়েন্টারগুলির উপস্থাপনের বৈশিষ্ট্যগুলি ধরে নেওয়া, যেমন পয়েন্টার ট্যাগিংয়ের জন্য

  • ধরে নিই যে ডেটা পয়েন্টার এবং কোড পয়েন্টারগুলির একই আকার রয়েছে

রিলিজ ম্যানেজমেন্টের ব্যবহারিক উদ্বেগও রয়েছে। যদি আমি কেবল একটি x86 বিল্ডটি তৈরি করি তবে এটি রেজিস্ট্রিগুলির সীমিত প্রাপ্যতার কারণে সম্ভবত আরও ধীরে ধীরে হলেও x86-64 এ চলবে। আমি যদি x86 এবং x86-64 উভয়ের জন্য তৈরি করি তবে আমার এখন উভয় আর্কিটেকচারের উপর পরীক্ষা করতে হবে এবং কেবল একটি আর্কিটেকচারে উত্পন্ন হতে পারে এমন বাগগুলির সাথে ডিল করতে হবে, যাতে নতুন রিলিজের শিপিংয়ের ব্যয় বাড়বে।


10
নোট করুন যে কোনও বাগ লেখা সম্ভব যা কেবলমাত্র তখনই প্রকাশ পায় যখন কোনও x86 বাইনারি ওএসের bit৪ বিট সংস্করণে চালিত হয়। এটি কেবল আরও শক্ত ;-)
স্টিভ জেসোপ

6
+1 টি। আমি "রিলিজ ম্যানেজমেন্ট" এর পয়েন্টে নিম্নলিখিতগুলি যুক্ত করতে চাই: যদি আমার সফ্টওয়্যার একটি নির্দিষ্ট উপাদানটির 32 এবং 64 বিট সংস্করণ উপলব্ধ থাকে, তবুও তৃতীয় পক্ষের উপাদানগুলির উপর নির্ভর করে তবে নতুন রিলিজ পরীক্ষার জন্য অতিরিক্ত প্রচেষ্টা আন্ডাররেটেড করা উচিত নয়। সুতরাং আইএমএইচও রিলিজ ম্যানেজমেন্ট সেই তালিকার প্রথম পয়েন্ট হওয়া উচিত , কেবল কোনও পার্শ্ব নোট নয়।
ডক ব্রাউন

আপনি কি ইন্টি পয়েন্টার সাইজ ইস্যুতে বিস্তারিত বলতে পারবেন? এটি কি কারণ bit৪ বিট পরিবেশে, কোনও মঞ্জুরীর চেয়ে মেমরির স্থানটি বেশি হবে?
ট্যাঙ্কোরস্যামশ

4
@ ট্যানকোরস্যামশ: x86 এ সাধারণত sizeof(int) == sizeof(void *)(তারা উভয়ই 32 বিট); x86_64 এ, int32 বিট রাখা স্বাভাবিক (এটি x86 এর সাথে সামঞ্জস্যপূর্ণ থাকে এবং স্মৃতিতে স্থান নষ্ট করা এড়াতে পারে) তবে পয়েন্টারগুলি 64৪ বিট হতে হবে (যেহেতু ভার্চুয়াল ঠিকানার স্থানটি ^ ^ to৪ পর্যন্ত যায়), সুতরাং তারা আর থাকতে পারে না একটি intবা মধ্যে shoved unsigned int
মাত্তেও ইটালিয়া

26

32 এবং 64 বিট উভয় ইন্টেল / এএমডি উভয়ের জন্যই সংকলন করা হলে বেশিরভাগ সফ্টওয়্যার একই কাজ করবে। তবে কিছু সফ্টওয়্যার আসবে না। অলসতা বা বৃহত্তর শ্রোতার কাছে পৌঁছানো ছাড়াও কয়েকটি নির্দিষ্ট কারণ রয়েছে যে কেন 64 বিট হিসাবে পুনরায় সংযোগ করা কাজ করবে না।

  • সফ্টওয়্যারটি অনিরাপদ পয়েন্টার অপারেশনগুলি ব্যবহার করতে পারে। সম্ভবত কোনও প্রোগ্রাম একটি পয়েন্টারকে একটি ইনট মধ্যে রাখে যা বেশিরভাগ সি এবং সি ++ সংকলকগুলির জন্য সাধারণত 32 বিট। পয়েন্টারগুলি একটি 64 বিট প্রোগ্রামে 64 বিট হয়। যে কাজ করে না।

  • বিট শিফট ক্রিয়াকলাপগুলি পৃথক আকারের ফলাফল তৈরি করতে পারে যদি ব্যবহৃত পূর্ণসংখ্যার ধরনটি ভিন্ন আকারের হয়। স্ট্যান্ডার্ড টাইপডেফের পরিবর্তে নিয়মিত ডেটা টাইপ ব্যবহার করার সময় এটি একটি সমস্যা হতে পারেint32_t

  • ইউনিয়নে ব্যবহৃত একটি ডেটা টাইপ মাপ পরিবর্তন করতে পারে, ইউনিয়নের আচরণ পরিবর্তন করে।

  • সফ্টওয়্যার কেবল 32-বিট লাইব্রেরিতে নির্ভর করতে পারে। সাধারণভাবে, স্ট্যাক, পয়েন্টার ইত্যাদির অনুমানের কারণে একটি 64 বিট প্রোগ্রাম কেবলমাত্র 64 বিট লাইব্রেরি নিয়ে কাজ করবে

আপনার প্রশ্নে আপনি যে অসুবিধা সম্পর্কে জিজ্ঞাসা করছেন সেগুলি হ'ল কিছু কোড বেসগুলিতে কয়েক মিলিয়ন কোডের কোড থাকতে পারে যা অনিরাপদ অপারেশন করে, অনিরাপদ অনুমান করে, শর্টকাট এবং বিকাশকারীদের দ্বারা চালিত "অপ্টিমাইজেশন" রাখতে পারে। কোডটি হয় একটি 64 বিট পরিবেশে সংকলন করবে না, বা এটি সংকলন করবে তবে শো-স্টপার বাগ থাকবে। সমস্ত সমস্যা সমাধান করতে দীর্ঘ সময় নিতে পারে। A৪ বিটের সংস্করণ প্রকাশ করা সম্ভব না হওয়া পর্যন্ত কোনও সংস্থা সময়ের সাথে তাদের সংশোধন করবে। হতে পারে কোনও সংস্থা বর্তমান রক্ষণাবেক্ষণ প্রকাশের পাশাপাশি একটি "সংস্করণ 2" বিকাশ করবে কারণ মোট পুনর্লিখন প্রয়োজনীয়।

গল্পটির নৈতিকতা হল পরিষ্কার কোড লিখুন এবং সংকলকটিকে দ্বিতীয়-অনুমান করার চেষ্টা করবেন না বা প্রয়োজনীয় নয় এমন চতুর অপ্টিমাইজেশান যুক্ত করার চেষ্টা করবেন না, সফ্টওয়্যারটি ভেঙে ফেলতে পারে, এবং সম্ভবত কোনওভাবে সহায়তা করবে না।

এই নিবন্ধটি আমি এই উত্তরে অন্তর্ভুক্ত করার আশা করতে পারি তার থেকে আরও বিশদে চলে গেছে: 64৪ -বিট প্ল্যাটফর্মে সি ++ কোড পোর্ট করার 20 টি সমস্যা


8
বিষয়গুলি কেবল সংকলনের চেয়ে আরও বেশি এগিয়ে যেতে পারে; আমার একটি মিস্ত্রি বন্ধু রয়েছে যা উপলব্ধ -৪-বিট এফএল স্টুডিও ব্যবহার করতে পারে না কারণ তাদের অনেকগুলি ভিএসটিই প্রয়োজন যা কেবল 32 বিট; অন্যান্য গতিশীল-লিঙ্ক ভিত্তিক প্লাগইন আর্কিটেকচার একই সাথে প্রভাবিত হয়।
স্টারওয়েভার

সম্পাদনার জন্য ধন্যবাদ: আমি সাধারণত ব্যাকরণ সম্পর্কে খুব পছন্দ করি তবে কয়েকটি ভুল করেছি। এবং @ স্টারওয়েভার আমি যখনই বলেছিলাম যে কোডটি সংকলন করতে পারে তবে এতে বাগ রয়েছে তবে আমি এটির প্রতি স্পর্শ করেছি। এটি এখনও যে ভাষা এবং প্ল্যাটফর্মকে আপনি টার্গেট করছেন তার জন্য ক্লিন কোড লেখার বিষয়ে আমার পয়েন্টটিতে ফিরে যায়।

"শো-স্টপার বাগ রয়েছে" শো স্টপারটি সুস্পষ্ট এবং "আপনার মুখে" এবং মোকাবিলা করা যেতে পারে। আমার মনে হয় যেটি সম্ভবত সবচেয়ে খারাপ এটি হ'ল সমস্ত সমস্যা যা সঠিকভাবে ভুল ফলাফল দেয় যা দীর্ঘ সময়ের জন্য অদৃশ্য হয়ে যায়।
বুরহান আলী
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.