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

{{Short description|Assigning or adjusting addresses at runtime}}
पुनसंख्यांकन के साथ भ्रमित नहीं होना चाहिए। 

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

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

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



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

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



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

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

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

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

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

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


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

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

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

== यह भी देखें ==
* लिंकर (कंप्यूटिंग)
* [[स्टेटिक लाइब्रेरी|लाइब्रेरी]] (कम्प्यूटिंग)
* आब्जेक्ट फ़ाइल
* [[पूर्वबाध्यकारी]]
* [[स्टेटिक लाइब्रेरी]]
* स्व-स्थानांतरण
* स्थिति-स्वतंत्र कोड (पीआईसी)
* [[रिबेसिंग]]
* [[कचरा संग्रह (कंप्यूटिंग)]]
* तेज सूचक, सूचक परिवर्तन का वास्तविक प्रारूप 
* [[स्थानांतरित करने योग्य वस्तु मॉड्यूल प्रारूप|स्थानांतरित करने योग्य आब्जेक्ट मॉड्यूल प्रारूप]]

== संदर्भ ==
{{Reflist|refs=
<ref name="Intel_iRMX">{{cite book |title=iRMX 86 Application Loader Reference Manual |publisher=[[Intel]] |url=http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/iRMX/iRMX_86_Rev_6_Mar_1984/146196_Burst/iRMX_86_Application_Loader_Reference_Manual.pdf |access-date=2020-01-11 |url-status=live |archive-url=https://web.archive.org/web/20200111215002/http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/iRMX/iRMX_86_Rev_6_Mar_1984/146196_Burst/iRMX_86_Application_Loader_Reference_Manual.pdf |archive-date=2020-01-11 |chapter=Types of Object Code |pages=((1{{hyphen}}2–1{{hyphen}}3)) |quote=[…] ''Absolute code'', and an absolute object module, is code that has been processed by LOC86 to run only at a specific location in memory. The [[Loader (computing)|Loader]] loads an absolute object module only into the specific location the module must occupy. ''[[Position-independent code]]'' (commonly referred to as PIC) differs from absolute code in that PIC can be loaded into any memory location. The advantage of PIC over absolute code is that PIC does not require you to reserve a specific block of memory. When the Loader loads PIC, it obtains [[iRMX&nbsp;86]] memory segments from the pool of the calling task's job and loads the PIC into the segments. A restriction concerning PIC is that, as in the [[PL/M-86]] COMPACT model of segmentation […], it can have only one code segment and one data segment, rather than letting the base addresses of these segments, and therefore the segments themselves, vary dynamically. This means that PIC programs are necessarily less than 64K bytes in length. PIC code can be produced by means of the BIND control of LINK86. ''Load-time locatable code'' (commonly referred to as LTL code) is the third form of object code. LTL code is similar to PIC in that LTL code can be loaded anywhere in memory. However, when loading LTL code, the Loader changes the base portion of pointers so that the pointers are independent of the initial contents of the registers in the microprocessor. Because of this fixup (adjustment of base addresses), LTL code can be used by tasks having more than one code segment or more than one data segment. This means that LTL programs may be more than 64K bytes in length. [[FORTRAN 86]] and [[Pascal 86]] automatically produce LTL code, even for short programs. LTL code can be produced by means of the BIND control of LINK86. […]}}</ref>
<ref name="Levine_1999_CH1_CH3">{{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-date=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 1: Linking and Loading & Chapter 3: Object Files |pages=5<!-- , --> |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]</ref>
<ref name="Borland_2007">{{cite web |author=Borland |author-link=Borland |title=Borland article #15961: Coping with 'Fixup Overflow' messages. |orig-date=1998-07-02 |date=1999-09-01 |series=Technical Information Database - Product: Borland C++ 3.1 |work=community.borland.com |id=TI961C.txt #15961 |url=http://vmlinux.org/~jakov/community.borland.com/15961.html |access-date=2007-01-15 |url-status=live |archive-url=https://web.archive.org/web/20080707030831/http://vmlinux.org/~jakov/community.borland.com/15961.html |archive-date=2008-07-07}}</ref>
<ref name="ELF">{{cite web |title=Executable and Linkable Format (ELF) |series=Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 |website=skyfree.org |url=http://www.skyfree.org/linux/references/ELF_Format.pdf |access-date=2018-10-01 |url-status=live |archive-url=https://web.archive.org/web/20191224125108/http://www.skyfree.org/linux/references/ELF_Format.pdf |archive-date=2019-12-24}}</ref>
}}


== अग्रिम पठन ==
* {{cite book |title=11/34 Memory Management Basic Logic test |author-first=Glenn |author-last=Johnson |publisher=[[Digital Equipment Corporation]] (DEC) |date=1975-12-21 |orig-date=1975-11-13 |id=MAINDEC-11-DFKTA-A-D |url=https://archive.org/stream/bitsavers_decpdp11xxAINDEC11DFKTAAD1134MEMORYMANAGEMENTBASIC_2477046/MAINDEC-11-DFKTA-A-D_1134_MEMORY_MANAGEMENT_BASIC_LOGIC_Dec75 |access-date=2017-08-19}}
* {{cite magazine |title=A Proposed Microprocessor Software Standard |author-first1=Peter G. |author-last1=Formaniak |author-first2=David |author-last2=Leitch |series=Technical Forum |magazine=[[BYTE]] - the small systems journal |publisher=[[Byte Publications, Inc.]] |publication-place=Peterborough, New Hampshire, USA |volume=2 |number=7 |date=July 1977 |id=ark:/13960/t32245485 |pages=34, 62–63 |url=https://archive.org/details/byte-magazine-1977-07/page/n35/mode/1up |access-date=2021-12-06}} (3 pages) (NB. Describes a [[Mostek hex format|relocatable hex format]] by [[Mostek]].)
* {{cite magazine |title=Relocatable Object Code Formats |author-first1=Carol Anne |author-last1=Ogdin |author-first2=Neil |author-last2=Colvin |author-first3=Tom |author-last3=Pittman |author-first4=Philip |author-last4=Tubb |series=Technical Forum |magazine=[[BYTE]] - the small systems journal |publisher=[[Byte Publications, Inc.]] |publication-place=Peterborough, New Hampshire, USA |volume=2 |number=11 |date=November 1977 |id=ark:/13960/t59c88b4h, ark:/13960/t3kw76j24 |pages=198–205 |url=https://archive.org/details/byte-magazine-1977-11-rescan/page/n199/mode/1up |access-date=2021-12-06}} (8 pages) (NB. Describes a [[Technical Design Labs Relocable Object Module Format|relocatable hex format]] by [[Technical Design Labs|TDL]].)
* {{cite journal |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Arlen Kildall |title=A simple technique for static relocation of absolute machine code |journal=[[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia]] |publisher=[[People's Computer Company]] |volume=3 |issue=2 |id=#22<!-- |number=22 --> ark:/13960/t8hf1g21p |date=February 1978 |orig-date=<!-- November -->1976 |pages=10–13<!-- in the issue --> (66–69<!-- in the volume -->) |isbn=0-8104-5490-4<!-- of the volume --> |url=https://archive.org/details/dr_dobbs_journal_vol_03/page/n67/mode/1up |access-date=2017-08-19}} [https://web.archive.org/web/20170819141800/http://www.retrotechnology.com/dri/d_dri_refs.html][https://web.archive.org/web/20170819173516/http://archive.computerhistory.org/resources/access/text/2016/12/102762506-05-01-acc.pdf][https://archive.today/20170909091943/https://groups.google.com/forum/%23!msg/comp.os.cpm/TLHgIi16yTo/gupNB1ai8UQJ#!topic/comp.os.cpm/TLHgIi16yTo]. Originally presented at: {{cite conference |title=Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976 |editor-first=Harold A. |editor-last=Titus |chapter=A Simple Technique for Static Relocation of Absolute Machine Code |author-first=Gary Arlen |author-last=Kildall |journal=Asilomar Conference on Signals, Systems & Computers |author-link=Gary Arlen Kildall |<!-- written-at -->location=[[Naval Postgraduate School]], Monterey, California, USA |publisher=Western Periodicals Company |publication-place=Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA |date=1977 |orig-date=22–24 November 1976 |issn=1058-6393 |pages=420–424 |url=https://books.google.com/books?id=cyBGAQAAIAAJ&q=relocation |access-date=2021-12-06}} (609 pages). (This "resize" method, named ''page boundary relocation'', could be applied statically to a [[CP/M-80]] disk image using {{ill|MOVCPM|pl|MOVCPM (CP/M)}} in order to maximize the [[Transient Program Area|TPA]] for programs to run. It was also utilized dynamically by the CP/M debugger [[Dynamic Debugging Tool]] (DDT) to [[self-relocation|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'', [[Self-relocation#Ref-Paul-2002-Drivers|another variant]] of this method was later utilized by dynamically [[high memory area|HMA]] self-relocating [[Terminate-and-stay-resident program|TSRs]] like [[KEYB (DOS command)|KEYB]], [[SHARE (DOS command)|SHARE]], and [[NLSFUNC (DOS command)|NLSFUNC]] under [[DR DOS&nbsp;6.0]] and higher. A much more sophisticated and [[byte alignment|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).)
* {{cite news |title=unknown |editor-first=Sol |editor-last=Libes |publisher=Libes Inc. |publication-place=Mountainside, New Jersey, USA |newspaper=[[S-100 Micro Systems]] |volume=1 |date=1980–1981 |issue= |page=54 |url=https://books.google.com/books?id=vEosAQAAIAAJ&q=page+boundary+relocation |access-date=2021-12-06}}
* {{cite web |title=Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication |author-first1=Robert |author-last1=Huitt |author-first2=Gordon |author-last2=Eubanks |author-link2=Gordon Eubanks |author-first3=Thomas "Tom" Alan |author-last3=Rolander |author-link3=Thomas Alan Rolander |author-first4=David |author-last4=Laws |author-first5=Howard E. |author-last5=Michel |author-first6=Brian |author-last6=Halla |author-first7=John Harrison |author-last7=Wharton |author-link7=John Harrison Wharton |author-first8=Brian |author-last8=Berg |author-first9=Weilian |author-last9=Su |author-first10=Scott |author-last10=Kildall |author-link10=Scott Kildall |author-first11=Bill |author-last11=Kampe |editor-first=David |editor-last=Laws |date=2014-04-25 |location=Pacific Grove, California, USA |type=video transscription |id=CHM Reference number: X7170.2014 |publisher=[[Computer History Museum]] |url=https://archive.computerhistory.org/resources/access/text/2014/06/102746909-05-01-acc.pdf |access-date=2020-01-19 |url-status=live |archive-url=https://web.archive.org/web/20141227142045/http://archive.computerhistory.org/resources/access/text/2014/06/102746909-05-01-acc.pdf |archive-date=2014-12-27 |quote=[…] Laws: […] "dynamic relocation" of the OS. Can you tell us what that is and why it was important? […] [[Gordon Eubanks|Eubanks]]: […] what [[Gary Arlen Kildall|Gary]] did […] was […] mind boggling. […] I remember the day at the [[Naval Postgraduate School|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 [[little-endian|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 […]}} [https://ethw.org/Milestones:The_CP/M_Microcomputer_Operating_System,_1974][https://www.youtube.com/watch?v=HO6IPpL0y8g] (33 pages)
* {{cite journal |title=CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M |language=de |type=part 1 |author-first1=Eckhard |author-last1=Lieber |author-first2=Thomas |author-last2=von Massenbach |journal=[[c't - magazin für computertechnik]] |publisher=[[Heise Verlag]] |date=1987 |volume=1987 |issue=1 |pages=124–135 |postscript=;}} {{cite journal |title=CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M |language=de |type=part 2 |author-first1=Eckhard |author-last1=Lieber |author-first2=Thomas |author-last2=von Massenbach |journal=[[c't - magazin für computertechnik]] |publisher=[[Heise Verlag]] |date=1987 |volume=1987 |issue=2 |pages=78–85 |postscript=;}} {{cite web |title=RSM für CP/M 2.2 |language=de |date=2016-10-09 |author-first=Alex |author-last=Huck |work=Homecomputer DDR |url=http://hc-ddr.hucki.net/wiki/doku.php/cpm:rsm:ct |access-date=2016-11-25 |url-status=live |archive-url=https://web.archive.org/web/20161125023237/http://hc-ddr.hucki.net/wiki/doku.php/cpm%3Arsm%3Act |archive-date=2016-11-25}}
* {{cite web |title=Re: CP/M assembly language programming |author-first=Charles "Chuck" P. |author-last=Guzis |date=2015-03-16 |work=Vintage Computer Forum |series=Genre: CP/M and MP/M |url=http://www.vcfed.org/forum/showthread.php?46767-CP-M-assembly-language-programming&p=360328#post360328 |access-date=2020-02-01 |url-status=live |archive-url=https://web.archive.org/web/20200201052736/http://www.vcfed.org/forum/showthread.php?46767-CP-M-assembly-language-programming&p=360328 |archive-date=2020-02-01 |quote=[…] Ever wonder how {{ill|MOVCPM|pl|MOVCPM (CP/M)}} works? Since the [[BDOS]] and [[Console Command Processor|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 [[bitmap|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. […]}}
* {{cite web |title=Re: How does MOVCPM.COM work? |author-first=Charles "Chuck" P. |author-last=Guzis |date=2015-07-29 |work=Vintage Computer Forum |series=Genre: CP/M and MP/M |url=http://www.vcfed.org/forum/showthread.php?48532-How-does-MOVCPM-COM-work&p=376438#post376438 |access-date=2020-02-01 |url-status=live |archive-url=https://web.archive.org/web/20200201053054/http://www.vcfed.org/forum/showthread.php?48532-How-does-MOVCPM-COM-work=&p=376438 |archive-date=2020-02-01 |quote=[…] {{ill|MOVCPM|pl|MOVCPM (CP/M)}} 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. […]}}
* {{cite web |title=Re: Is it safe to use RST 28h in CP/M assembly programs? |author-first=Charles "Chuck" P. |author-last=Guzis |date=2016-11-08 |work=Vintage Computer Forum |series=Genre: CP/M and MP/M |url=http://www.vcfed.org/forum/showthread.php?54822-Is-it-safe-to-use-RST-28h-in-CP-M-assembly-programs&p=434954#post434954 |access-date=2020-02-01 |url-status=live |archive-url=https://web.archive.org/web/20200201053327/http://www.vcfed.org/forum/showthread.php?54822-Is-it-safe-to-use-RST-28h-in-CP-M-assembly-programs&p=434954 |archive-date=2020-02-01 |quote=[…] I've referenced PRL files and how they originally got their start with {{ill|MOVCPM|pl|MOVCPM (CP/M)}}, but became an integral part of [[MP/M]] and [[CP/M 3.0]]. But PRL files use a [[bitmap|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 [[runtime (program lifecycle phase)|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. […]}}
* {{cite journal |author-first=Richard L. |author-last=Roth |title=Relocation Is Not Just Moving Programs |location=Ridgefield, CA, USA |journal=[[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia]] |publisher=[[People's Computer Company]] |id=#22 |volume=3 |number=2 |date=February 1978 |orig-date=1977 |pages=14–20<!-- in the issue --> (70–76<!-- in the volume -->) |isbn=0-8104-5490-4<!-- of the volume --> |url=https://archive.org/stream/dr_dobbs_journal_vol_03/dr_dobbs_journal_vol_03_djvu.txt |access-date=2019-04-19 |url-status=live |archive-url=https://web.archive.org/web/20190420010941/https://archive.org/stream/dr_dobbs_journal_vol_03/dr_dobbs_journal_vol_03_djvu.txt |archive-date=2019-04-20}}
* {{cite book |title=Assemblers, Compilers, and Program Translation |chapter=8.2.2 Relocating Loader |pages=[https://archive.org/details/assemblerscompil00cali/page/237 237]–241 |author-first=Peter |author-last=Calingaert |editor-first=Ellis |editor-last=Horowitz |editor-link=Ellis Horowitz |date=1979 |orig-date=1978-11-05 |series=Computer software engineering series |publisher=[[Computer Science Press, Inc.]] |publication-place=Potomac, Maryland, USA |location=[[University of North Carolina at Chapel Hill]] |edition=1st printing, 1st |isbn=0-914894-23-4 |issn=0888-2088 |lccn=78-21905 |url=https://archive.org/details/assemblerscompil00cali |url-access=registration |access-date=2020-03-20}} (2+xiv+270+6 pages)
* {{cite book |title=The Microsoft OBJ File Format |publisher=[[Microsoft]], Product Support Services |id=Application Note SS0288 |url=https://www.fileformat.info/format/ms-obj/corion.htm |access-date=2017-08-21 |url-status=live |archive-url=https://archive.today/20170909092856/http://www.fileformat.info/format/ms-obj/corion.htm |archive-date=2017-09-09}}
* {{cite book |author-first1=Andrew Stuart |author-last1=Tanenbaum |author-link1=Andrew Stuart Tanenbaum |author-first2=Herbert |author-last2=Bos |title=Modern Operating Systems |edition=4 |date=2015 |publisher=[[Pearson Education Inc.]] |isbn=978-0-13359162-0}}
* {{cite web |author-first=John C. |author-last=Elliott |title=PRL file format |date=2012-06-05 |orig-date=2000-01-02 |website=seasip.info |url=https://www.seasip.info/Cpm/prl.html |access-date=2020-01-26 |url-status=live |archive-url=https://web.archive.org/web/20200126182027/https://www.seasip.info/Cpm/prl.html |archive-date=2020-01-26 |quote=[…] A PRL file is a relocatable binary file, used by [[MP/M]] and [[CP/M Plus]] for various modules other than [[.COM file]]s. 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|OVL]] ([[overlay (programming)|overlay]]) files, which have a PRL header but are not relocatable. [[Graphics System Extension|GSX]] drivers are in PRL format; so are [[Resident System Extension]]s (.RSX). […]}} [https://www.seasip.info/Cpm/amsfid.html#PRL%20file%20format]
* {{cite web |author-first=John C. |author-last=Elliott |title=Microsoft REL format |date=2012-06-05 |orig-date=2000-01-02 |website=seasip.info |url=https://www.seasip.info/Cpm/rel.html |access-date=2020-01-26 |url-status=live |archive-url=https://web.archive.org/web/20200126181737/https://www.seasip.info/Cpm/rel.html |archive-date=2020-01-26 |quote=[…] The REL format is generated by [[Microsoft]]'s M80 and [[Digital Research]]'s RMAC. […]}}
* {{cite web |title=Support for PRL, page relocatable executable for MP/M |date=2018-09-05 |orig-date=2018-09-02 |author=feilipu |work=z88dk |url=https://github.com/z88dk/z88dk/issues/935 |access-date=2020-01-26 |url-status=live |archive-url=https://web.archive.org/web/20200201053652/https://github.com/z88dk/z88dk/issues/935 |archive-date=2020-02-01 |quote=[…] 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. […]}}
* {{cite journal |title=Understanding Relocatable Code |series=The Next Step |author-first=Hardin |author-last=Brothers |journal=[[80 Micro]] |publisher=[[1001001, Inc.]] |issn=0744-7868 |date=April 1983 |issue=39 |pages=[https://archive.org/details/80-microcomputing-magazine-1983-04/page/n37 38], 40, 42, 45 |url=https://archive.org/details/80-microcomputing-magazine-1983-04 |access-date=2020-02-06}} [https://archive.org/stream/80-microcomputing-magazine-1983-04/80Microcomputing_0483_djvu.txt][https://archive.org/download/80-microcomputing-magazine-1983-04/80Microcomputing_0483_text.pdf]
* {{cite journal |title=Relocatable Programs: Microcomputing's Hoboes |series=The Next Step |author-first=Hardin |author-last=Brothers |journal=[[80 Micro]] |publisher=[[CW Communications/Peterborough, Inc.]] |issn=0744-7868 |date=April 1985 |issue=63 <!-- |contribution=illustration |contributor-first=Peter |contributor-last=Bono --> |pages=[https://archive.org/details/80-microcomputing-magazine-1985-04/page/n99 98], 100, 102–103 |url=https://archive.org/details/80-microcomputing-magazine-1985-04 |access-date=2020-02-06}} [https://archive.org/stream/80-microcomputing-magazine-1985-04/80Microcomputing_0485_djvu.txt][https://archive.org/download/80-microcomputing-magazine-1985-04/80Microcomputing_0485_text.pdf]
<!-- * Jesse Bob Overholt column: The Alternate Source Journal #16 James Farvour Microsoft BASIC Decoded And Other Mysteries POP HL, JP (HL) E1h E9h at offset 000Bh (+11) -->
* {{cite journal |title=ZCPR 3.4 - Type-4 Programs |series=ZCPR3 Corner |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=May–June 1988 |location=Columbia Falls, Montana, USA |issue=32 |pages=[https://archive.org/details/the-computer-journal-32/page/n10/mode/1up 10]–17 [<nowiki/>[https://archive.org/details/the-computer-journal-32/page/n15/mode/1up 15]–16] |id=ark:/13960/t1wd4v943 |url=https://archive.org/details/the-computer-journal-32 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-32/tcj_32_May-June_1988_djvu.txt][https://archive.org/download/the-computer-journal-32/tcj_32_May-June_1988_text.pdf]
* {{cite journal |title=Z3PLUS & Relocation - Information on ZCPR3PLUS, and how to write self relocating Z80 code |series=Advanced CP/M |author-first=Bridger |author-last=Mitchell |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=July–August 1988 |location=Columbia Falls, Montana, USA |issue=33 |pages=[https://archive.org/details/the-computer-journal-33/page/n10/mode/1up 9]–15 |id=ark:/13960/t36121780 |url=https://archive.org/details/the-computer-journal-33 |access-date=2020-02-09}} [https://archive.org/stream/the-computer-journal-33/tcj_33_July-August_1988_djvu.txt][https://archive.org/download/the-computer-journal-33/tcj_33_July-August_1988_text.pdf]
* {{cite journal |title=More on relocatable code, PRL files, ZCPR34, and Type-4 programs |series=ZCPR3 Corner |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=September–October 1988 |location=Columbia Falls, Montana, USA |issue=34 |pages=[https://archive.org/details/the-computer-journal-34/page/n20/mode/1up 20]–25 |id=ark:/13960/t0ks7pc39 |url=https://archive.org/details/the-computer-journal-34 |access-date=2020-02-09}} [https://archive.org/stream/the-computer-journal-34/tcj_34_September-October_1988_djvu.txt][https://archive.org/download/the-computer-journal-34/tcj_34_September-October_1988_text.pdf][https://web.archive.org/web/20170831184307/http://gaby.de/ftp/pub/cpm/znode51/articles/tcj/tcj34.ws]
* {{cite journal |title=Ten Years of ZCPR |series=Z-System Corner |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first1=Art |editor-last1=Carlson |editor-first2=Chris |editor-last2=McEwen |date=January–February 1992 |publisher=Socrates Press |location=S. Plainfield, New Jersey, USA |issue=54 |pages=[https://archive.org/details/the-computer-journal-54/page/n4/mode/1up 3]–7 |id=ark:/13960/t89g6n689 |url=https://archive.org/details/the-computer-journal-54 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-54/tcj_54_January-February_1992_djvu.txt][https://archive.org/download/the-computer-journal-54/tcj_54_January-February_1992_text.pdf][https://web.archive.org/web/20170831184437/http://gaby.de/ftp/pub/cpm/znode51/articles/tcj/tcj54.ws]
* {{cite journal |title=Type-3 and Type-4 Programs |series=Z-System Corner - Some New Applications of Type-4 Programs |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first1=Art |editor-last1=Carlson |editor-first2=Chris |editor-last2=McEwen |date=May–June 1992 |orig-date=March–June 1992 |publisher=Socrates Press |location=S. Plainfield, New Jersey, USA |issue=55 |pages=[https://archive.org/details/the-computer-journal-55/page/n14/mode/1up 13]–19 |id=ark:/13960/t4dn54d22 |url=https://archive.org/details/the-computer-journal-55 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-55/tcj_55_March-June_1992_djvu.txt][https://archive.org/download/the-computer-journal-55/tcj_55_March-June_1992_text.pdf]
* {{cite journal |title=Writing Relocatable Code - Some embedded code must run at more than one address |author-first=Jack |author-last=Ganssle |journal=Embedded Systems Programming |date=February 1992 |publisher=The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG |url=http://www.ganssle.com/articles/arelocat.htm |access-date=2020-02-20 |url-status=live |archive-url=https://web.archive.org/web/20190718232931/http://www.ganssle.com/articles/arelocat.htm |archive-date=2019-07-18}}

{{Application binary interface}}
{{Executables}}
[[Category: कंप्यूटर पुस्तकालय]] [[Category: असाइनमेंट संचालन]] 



[[Category: Machine Translated Page]]
[[Category:Created On 18/02/2023]]