स्थानांतरण (कंप्यूटिंग)

रिलोकेशन (स्थानांतरण ) स्थिति-निर्भर कोड और प्रोग्राम के डेटा के लिए लोड एड्रेस निर्धारित करने और निर्धारित किए गए एड्रेस को प्रतिबिंबित करने के लिए कोड और डेटा को समायोजित करने की प्रक्रिया है।मल्टीप्रोसेस प्रणाली के आने से पूर्व, और अभी भी कई एम्बेडेड प्रणाली में, वस्तुओं के एड्रेस ज्ञात स्थान से प्रारम्भ होने वाले पूर्ण एड्रेस अधिकांशतः शून्य थे। चूंकि मल्टीप्रोसेसिंग प्रणाली गतिशील प्रकार से प्रोग्राम के बीच लिंक और स्विच करते हैं, इसलिए स्थिति-स्वतंत्र कोड का उपयोग करके वस्तुओं को स्थानांतरित करने में सक्षम होना आवश्यक हो गया है। लिंकर (कंप्यूटिंग) सामान्य तौर पर प्रतीक संकल्प के संयोजन के साथ स्थानांतरण करता है, प्रोग्राम चलाने से पूर्व प्राथमिक भंडारण में वास्तविक प्रयोग करने योग्य एड्रेस के साथ प्रतीकात्मक संदर्भों या पुस्तकालय (कंप्यूटर विज्ञान) के नामों को बदलने के लिए फ़ाइलों और पुस्तकालयों को ढूंढने की प्रक्रिया होती है।

रिलोकेशन सामान्य तौर पर लिंकर द्वारा लिंक समय पर किया जाता है, परन्तु यह लोड होने का समय पर स्थानांतरित लोडर (कंप्यूटिंग), या रन टाइम (प्रोग्राम लाइफसाइकिल फेज (जीवनचक्र चरण)) पर चल रहे प्रोग्राम स्व-स्थानांतरण द्वारा भी किया जा सकता है। कुछ आर्किटेक्चर (निर्माण) रन टाइम के लिए एड्रेस कार्यभार को स्थगित कर पूरी तरह से स्थानांतरण से बचते हैं; उदाहरण के लिए, स्टैक मशीनों में शून्य एड्रेस अंकगणित या कुछ खंडित निर्माण में जहां प्रत्येक संकलन इकाई को अलग खंड में लोड किया जाता है।

विभाजन

ऑब्जेक्ट फाइल (वस्तु फ़ाइल) को विभिन्न मेमोरी विभाजन प्रकारों में विभाजित किया गया है। उदाहरण सेगमेंट (खंड) में कोड खंड (.टेक्स्ट) प्रारंभिक डेटा खंड (.डेटा), अप्रराम्भिक डेटा खंड (.बीएसएस) या अन्य उपस्थित हैं

स्थानांतरण तालिका

स्थानांतरण तालिका अनुवादक (संकलक या असेंबलर (कंप्यूटर प्रोग्रामिंग)) द्वारा बनाई गई सूचक (कंप्यूटर प्रोग्रामिंग) की सूची है और बिषय या निष्पादन योग्य फ़ाइल में संग्रहीत है। तालिका में प्रत्येक प्रविष्टि, या फ़िक्सअप, बिषय कोड में पूर्ण पते के लिए सूचक (कंप्यूटर प्रोग्रामिंग) है जिसे लोडर द्वारा प्रोग्राम को स्थानांतरित करने पर बदला जाना चाहिए जिससे की यह सही स्थान को संदर्भित कर सकता है। फ़िक्सअप को पूर्ण इकाई के रूप में प्रोग्राम के स्थानांतरण का समर्थन करने के लिए डिज़ाइन किया गया है। कुछ कारणों में, तालिका में प्रत्येक फ़िक्सअप स्वयं शून्य के आधारित एड्रेस के सापेक्ष होता है, इसलिए फ़िक्सअप स्वयं को बदलना चाहिए क्योंकि लोडर तालिका के माध्यम से आगे बढ़ता है।

कुछ विषय में फ़िक्सअप जो कुछ सीमाओं (जैसे खंड सीमा) को पार करता है या जो शब्द सीमा पर संरेखित नहीं है, वह विरुद्ध है और लिंकर द्वारा त्रुटि के रूप में चिन्हित किया जाता है।

डॉस और 16-बिट विंडोज

सूचक दूरी (कंप्यूटर प्रोग्रामिंग) (एक्स86 मेमोरी खंड के साथ 32-बिट सूचक: ऑफ़सेट, डीओएस कंप्यूटर प्रोग्राम के लिए उपलब्ध 20-बिट 640 किलोबाइट कंप्यूटर भंडारण स्थान को संबोधित करने के लिए उपयोग किया जाता है), जो डीओएस निष्पादन योग्य (इएक्सइ) के भीतर कोड या डेटा को इंगित करता है। पूर्ण खंड नहीं हैं, क्योंकि कोड/डेटा का वास्तविक मेमोरी एड्रेस इस बात पर निर्भर करता है कि प्रोग्राम को मेमोरी में कहाँ भरा गया है और प्रोग्राम लोड होने तक यह ज्ञात नहीं है।

इसके विपरीत, खंड डीओएस इएक्सइ फ़ाइल में सापेक्ष मान हैं। निष्पादन योग्य मेमोरी में भरे होने पर इन खंड को सही करने की आवश्यकता है। इएक्सइ लोडर (कंप्यूटिंग) उन खंडों को ढूंढने के लिए स्थानांतरण तालिका का उपयोग करता है जिन्हें समायोजित करने की आवश्यकता होती है।

32-बिट विंडोज

32-बिट विंडोज ऑपरेटिंग प्रणाली के साथ, इएक्सइ फाइलों के लिए स्थानांतरण टेबल प्रदान करना अनिवार्य नहीं है, क्योंकि वे आभासी एड्रेस के रिक्त स्थान में भरी गई पहली इमेज हैं और इस तरह उनके पसंदीदा बेस एड्रेस पर भरी जाती है ।

डायनेमिक लिंक लाइब्रेरी और इएक्सइ दोनों के लिए जो एड्रेस स्पेस लेआउट रैंडमाइजेशन (एएसएलआर) में ऑप्ट इन करते हैं, विंडोज विस्टा के साथ प्रारम्भ की गई अपने कार्य में लेन वाला लघुकरण तकनीक, एक बार फिर से स्थानांतरण तालिका अनिवार्य हो जाती है क्योंकि संभावना है कि बाइनरी को पहले गतिशील प्रकार से स्थानांतरित किया जा सकता है। तथापि वे अभी भी आभासी एड्रेस स्थान में भरी गयी पहली चीज़ हैं।

64-बिट विंडोज

विंडोज विस्टा और ऊपर के संस्करण पर नेटिव 64-बिट बायनेरिज़ चलाते समय, एएसएलआर अनिवार्य है, और इस प्रकार स्थानांतरण अनुभागों को संकलक द्वारा छोड़ा नहीं जा सकता है।

यूनिक्स जैसी प्रणाली

निष्पादन योग्य और लिंक करने योग्य प्रारूप (ईएलएफ) और अधिकांशतः यूनिक्स जैसी प्रणालियों द्वारा उपयोग किए जाने वाले साझा पुस्तकालय प्रारूप में कई प्रकार के स्थानांतरण को परिभाषित करने की अनुमति मिलती है।

स्थानांतरण प्रक्रिया

लिंकर ऑब्जेक्ट फ़ाइलों में खंड की जानकारी और स्थानांतरण तालिका पढ़ता है और इसके द्वारा स्थानांतरित करता है:

• सामान्य प्रकार के सभी खंडों को उस प्रकार के खंड में विलय करना है।
• सभी कोड (फ़ंक्शंस) और डेटा (वैश्विक चर) अद्वितीय रन टाइम एड्रेस देते हुए, प्रत्येक अनुभाग और प्रत्येक प्रतीक के लिए अद्वितीय रन टाइम एड्रेस निर्दिष्ट करना है।
• स्थानांतरण तालिका को संशोधित करने की चर्चा करते हुए प्रतीक जिससे की वे सही रन टाइम एड्रेस को इंगित करते हैं।

उदाहरण

निम्नलिखित उदाहरण डोनाल्ड नुथ की मिक्स विषय और मिक्सल असेंबली भाषा का उपयोग करता है। सिद्धांत किसी भी वास्तुकला के लिए समान हैं, चूँकि विवरण बदल जाएगा।

• (ए) प्रोग्राम एसयुबीआर को ऑब्जेक्ट फ़ाइल (B) बनाने के लिए संकलित किया गया है, जो मशीन कोड और असेंबलर दोनों के प्रकार में दर्शाया गया है। संकलक संकलित कोड को स्वेच्छाचरित प्रकार से स्थान पर प्रारम्भ कर सकता है, जैसा कि अधिकांशतः स्थान 1 दिखाया गया है। स्थान 13 में स्थान 5 में कथन एसटी के लिए जंप निर्देश के लिए मशीन कोड सम्मिलित है।
• (सी) यदि एसयुबीआर बाद में अन्य कोड से जुड़ा हुआ है तो इसे 1 के अतिरिक्त किसी अन्य स्थान पर संग्रहीत किया जा सकता है। इस उदाहरण में लिंकर इसे स्थान 120 पर रखता है। जंप इंस्ट्रक्शन (निर्देश) जो अब स्थान 133 पर है, कथन एसटी के लिए 125 कोड के नए स्थान को इंगित करने के लिए 'स्थानांतरित' किया जाना चाहिए। [निर्देश में दर्शाया गया 161 मिक्स मशीन कोड 125 का प्रतिनिधित्व है]।
• (डी) जब प्रोग्राम को चलाने के लिए मेमोरी में भरा जाता है तो इसे लिंकर द्वारा निर्दिष्ट स्थान के अतिरिक्त किसी अन्य स्थान पर भरा जा सकता है। यह उदाहरण एसयुबीआर को अब स्थान 300 पर दर्शाता है। जंप निर्देश में एड्रेस, अब 313 पर, फिर से स्थानांतरित करने की आवश्यकता है जिससे की यह एसटी, 305 के अद्यतन स्थान की तरफ इंगित कर सकता है। [4 49 305 का मिक्स मशीन प्रतिनिधित्व है]।

यह भी देखें

• लिंकर (कंप्यूटिंग)
• लाइब्रेरी (कम्प्यूटिंग)
• आब्जेक्ट फ़ाइल
• पूर्वबाध्यकारी
• स्टेटिक लाइब्रेरी
• स्व-स्थानांतरण
• स्थिति-स्वतंत्र कोड (पीआईसी)
• रिबेसिंग
• कचरा संग्रह (कंप्यूटिंग)
• तेज सूचक, सूचक परिवर्तन का वास्तविक प्रारूप
• स्थानांतरित करने योग्य आब्जेक्ट मॉड्यूल प्रारूप

अग्रिम पठन

• Johnson, Glenn (1975-12-21) [1975-11-13]. 11/34 Memory Management Basic Logic test. Digital Equipment Corporation (DEC). MAINDEC-11-DFKTA-A-D. Retrieved 2017-08-19.
• Formaniak, Peter G.; Leitch, David (July 1977). "A Proposed Microprocessor Software Standard". BYTE - the small systems journal. Technical Forum. Vol. 2, no. 7. Peterborough, New Hampshire, USA: Byte Publications, Inc. pp. 34, 62–63. ark:/13960/t32245485. Retrieved 2021-12-06. (3 pages) (NB. Describes a relocatable hex format by Mostek.)
• Ogdin, Carol Anne; Colvin, Neil; Pittman, Tom; Tubb, Philip (November 1977). "Relocatable Object Code Formats". BYTE - the small systems journal. Technical Forum. Vol. 2, no. 11. Peterborough, New Hampshire, USA: Byte Publications, Inc. pp. 198–205. ark:/13960/t59c88b4h, ark:/13960/t3kw76j24. Retrieved 2021-12-06. (8 pages) (NB. Describes a relocatable hex format by TDL.)
• Kildall, Gary Arlen (February 1978) [1976]. "A simple technique for static relocation of absolute machine code". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. People's Computer Company. 3 (2): 10–13 (66–69). ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p. Retrieved 2017-08-19. [4][5][6]. Originally presented at: Kildall, Gary Arlen (1977) [22–24 November 1976]. "A Simple Technique for Static Relocation of Absolute Machine Code". Written at Naval Postgraduate School, Monterey, California, USA. In Titus, Harold A. (ed.). Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976. Asilomar Conference on Signals, Systems & Computers. Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA: Western Periodicals Company. pp. 420–424. ISSN 1058-6393. Retrieved 2021-12-06. (609 pages). (This "resize" method, named page boundary relocation, could be applied statically to a CP/M-80 disk image using MOVCPM in order to maximize the TPA for programs to run. It was also utilized dynamically by the CP/M debugger Dynamic Debugging Tool (DDT) to relocate itself into higher memory. The same approach was independently developed by Bruce H. Van Natta of IMS Associates to produce relocatable PL/M code. As paragraph boundary relocation, another variant of this method was later utilized by dynamically HMA self-relocating TSRs like KEYB, SHARE, and NLSFUNC under DR DOS 6.0 and higher. A much more sophisticated and byte-level granular method based on a somewhat similar approach was independently conceived and implemented by Matthias R. Paul and Axel C. Frinke for their dynamic dead-code elimination to dynamically minimize the runtime footprint of resident drivers and TSRs (like FreeKEYB).)
• Libes, Sol, ed. (1980–1981). "unknown". S-100 Micro Systems. Vol. 1. Mountainside, New Jersey, USA: Libes Inc. p. 54. Retrieved 2021-12-06. {{cite news}}: Cite uses generic title (help)
• Huitt, Robert; Eubanks, Gordon; Rolander, Thomas "Tom" Alan; Laws, David; Michel, Howard E.; Halla, Brian; Wharton, John Harrison; Berg, Brian; Su, Weilian; Kildall, Scott; Kampe, Bill (2014-04-25). Laws, David (ed.). "Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication" (PDF) (video transscription). Pacific Grove, California, USA: Computer History Museum. CHM Reference number: X7170.2014. Archived (PDF) from the original on 2014-12-27. Retrieved 2020-01-19. […] Laws: […] "dynamic relocation" of the OS. Can you tell us what that is and why it was important? […] Eubanks: […] what Gary did […] was […] mind boggling. […] I remember the day at the school he came bouncing into the lab and he said, I have figured out how to relocate. He took advantage of the fact that the only byte was always going to be the high order byte. And so he created a bitmap. […] it didn't matter how much memory the computer had, the operating system could always be moved into the high memory. Therefore, you could commercialize this […] on machines of different amounts of memory. […] you couldn't be selling a 64K CP/M and a 47K CP/M. It'd just be ridiculous to have a hard compile in the addresses. So Gary figured this out one night, probably in the middle of the night thinking about some coding thing, and this really made CP/M possible to commercialize. I really think that without that relocation it would have been a very tough problem. To get people to buy it, it'd seem complicated to them, and if you added more memory you'd have to go get a different operating system. […] Intel […] had the bytes reversed, right, for the memory addresses. But they were always in the same place, so you could relocate it on a 256 byte boundary, to be precise. You could therefore always relocate it with just a bitmap of where those […] Laws: Certainly the most eloquent explanation I've ever had of dynamic relocation […] [7][8] (33 pages)
• Lieber, Eckhard; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (part 1) (in Deutsch). Heise Verlag. 1987 (1): 124–135; Lieber, Eckhard; von Massenbach, Thomas (1987). "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". c't - magazin für computertechnik (part 2) (in Deutsch). Heise Verlag. 1987 (2): 78–85; Huck, Alex (2016-10-09). "RSM für CP/M 2.2". Homecomputer DDR (in Deutsch). Archived from the original on 2016-11-25. Retrieved 2016-11-25.
• Guzis, Charles "Chuck" P. (2015-03-16). "Re: CP/M assembly language programming". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] Ever wonder how MOVCPM works? Since the BDOS and CCP is in high memory, above the user application, addresses have to be changed every time the system memory size is changed. Now that requires relocating addresses in 8080 code, since relative addressing is not part of the hardware. Without implementing a full-blown relocating assembler and loader, how does one go about this? It's actually pretty clever and MP/M even uses this scheme to construct its page-relocatable files. You simply assemble the source program twice with the second assembly origin 100H (256 bytes) higher than the first. The two binary images are then compared, byte for byte, and a map constructed of where pairs of bytes differ in value by exactly 100H. The result is a list of locations where the relocation value needs to be adjusted if the location of a program in memory is to be moved. MP/M calls this sort of file PRL (page relocatable), but I don't know that CP/M 2.2 ever coined a name for it. […]
• Guzis, Charles "Chuck" P. (2015-07-29). "Re: How does MOVCPM.COM work?". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] MOVCPM uses an early type of PRL format. Basically, CP/M is assembled twice; the second time is 100H bytes offset. The two binaries are compared and a bitmap constructed. A set bit implies that the high-order byte of an address is to be adjusted. Low order address bytes are not affected; hence, "Page relocatable file". Each byte in the bitmap corresponds to 8 bytes in the binary data. […] So everything to be moved in MOVCPM is part of the image and its relocation bitmap. […]
• Guzis, Charles "Chuck" P. (2016-11-08). "Re: Is it safe to use RST 28h in CP/M assembly programs?". Vintage Computer Forum. Genre: CP/M and MP/M. Archived from the original on 2020-02-01. Retrieved 2020-02-01. […] I've referenced PRL files and how they originally got their start with MOVCPM, but became an integral part of MP/M and CP/M 3.0. But PRL files use a bit map in which every bit corresponds to a memory location; one bits indicate that a page relocation offset should be added to the corresponding memory location. If you have very few absolute memory references (as opposed to relative ones) you may want to employ a pointer list (2 bytes per reference) rather than a bitmap. This is unlikely in 8080 code which doesn't have relative jumps, but may be a consideration for Z80 code. The trick to quickly find this out is to assemble your program twice; the second time offset by 100H, then compare the two binaries. The advantage of run-time relocation is that you don't have to incur a penalty for code that attempts to get around the relocation issue--no "tricks"; just write straight code. […]
• Roth, Richard L. (February 1978) [1977]. "Relocation Is Not Just Moving Programs". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. Ridgefield, CA, USA: People's Computer Company. 3 (2): 14–20 (70–76). ISBN 0-8104-5490-4. #22. Archived from the original on 2019-04-20. Retrieved 2019-04-19.
• Calingaert, Peter (1979) [1978-11-05]. "8.2.2 Relocating Loader". Written at University of North Carolina at Chapel Hill. In Horowitz, Ellis (ed.). Assemblers, Compilers, and Program Translation. Computer software engineering series (1st printing, 1st ed.). Potomac, Maryland, USA: Computer Science Press, Inc. pp. 237–241. ISBN 0-914894-23-4. ISSN 0888-2088. LCCN 78-21905. Retrieved 2020-03-20. (2+xiv+270+6 pages)
• The Microsoft OBJ File Format. Microsoft, Product Support Services. Application Note SS0288. Archived from the original on 2017-09-09. Retrieved 2017-08-21.
• Tanenbaum, Andrew Stuart; Bos, Herbert (2015). Modern Operating Systems (4 ed.). Pearson Education Inc. ISBN 978-0-13359162-0.
• Elliott, John C. (2012-06-05) [2000-01-02]. "PRL file format". seasip.info. Archived from the original on 2020-01-26. Retrieved 2020-01-26. […] A PRL file is a relocatable binary file, used by MP/M and CP/M Plus for various modules other than .COM files. The file format is also used for FID files on the Amstrad PCW. There are several file formats which use versions of PRL: SPR (System PRL), RSP (Resident System Process). LINK-80 can also produce OVL (overlay) files, which have a PRL header but are not relocatable. GSX drivers are in PRL format; so are Resident System Extensions (.RSX). […] [9]
• Elliott, John C. (2012-06-05) [2000-01-02]. "Microsoft REL format". seasip.info. Archived from the original on 2020-01-26. Retrieved 2020-01-26. […] The REL format is generated by Microsoft's M80 and Digital Research's RMAC. […]
• feilipu (2018-09-05) [2018-09-02]. "Support for PRL, page relocatable executable for MP/M". z88dk. Archived from the original on 2020-02-01. Retrieved 2020-01-26. […] Out of the assembled Microsoft .REL files the linker has to generate a .PRL format executable for MP/M. The .PRL format is essentially a .COM file with some additional information to enable the program and its data to be relocated onto any page. What does a .PRL file look like? The first bytes are size of the program, followed by the program origin at 0x0100. Following the program, there is a bit-for-byte mask appended to allow the MP/M system to know which bytes in the program need to be changed when the program is relocated. How does the linker do that without disassembling the whole application? In advance the program is linked for two different origins 0x0100 and 0x0200, from the .REL objects. The linker trick is simply recognising which bytes in the two versions of the executable differ. These bytes are then recorded in the bit mask stored following the executable, and the final .PRL program is designed to run from 0x0100 plus its page offset. The same trick is done for the .RSP and .SPR executable files, except that both these formats forego the offset, and run from 0x0000 plus their page offset. […]
• Brothers, Hardin (April 1983). "Understanding Relocatable Code". 80 Micro. The Next Step. 1001001, Inc. (39): 38, 40, 42, 45. ISSN 0744-7868. Retrieved 2020-02-06. [10][11]
• Brothers, Hardin (April 1985). "Relocatable Programs: Microcomputing's Hoboes". 80 Micro. The Next Step. CW Communications/Peterborough, Inc. (63): 98, 100, 102–103. ISSN 0744-7868. Retrieved 2020-02-06. [12][13]
• Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17 [15–16]. ISSN 0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29. [14][15]
• Mitchell, Bridger (July–August 1988). Carlson, Art (ed.). "Z3PLUS & Relocation - Information on ZCPR3PLUS, and how to write self relocating Z80 code". The Computer Journal (TCJ) - Programming, User Support, Applications. Advanced CP/M. Columbia Falls, Montana, USA (33): 9–15. ISSN 0748-9331. ark:/13960/t36121780. Retrieved 2020-02-09. [16][17]
• Sage, Jay (September–October 1988). Carlson, Art (ed.). "More on relocatable code, PRL files, ZCPR34, and Type-4 programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (34): 20–25. ISSN 0748-9331. ark:/13960/t0ks7pc39. Retrieved 2020-02-09. [18][19][20]
• Sage, Jay (January–February 1992). Carlson, Art; McEwen, Chris (eds.). "Ten Years of ZCPR". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner. S. Plainfield, New Jersey, USA: Socrates Press (54): 3–7. ISSN 0748-9331. ark:/13960/t89g6n689. Retrieved 2021-11-29. [21][22][23]
• Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19. ISSN 0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29. [24][25]
• Ganssle, Jack (February 1992). "Writing Relocatable Code - Some embedded code must run at more than one address". Embedded Systems Programming. The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG. Archived from the original on 2019-07-18. Retrieved 2020-02-20.