نقل (حوسبة)

  لمعانٍ أخرى، طالع نقل (توضيح).

النقل هو عملية تعيين عناوين التحميل للرمز المعتمد على الموضع وبيانات البرنامج وتعديل الكود والبيانات لتعكس العناوين المخصصة. قبل ظهور أنظمة العمليات المتعددة، ولا تزال في العديد من الأنظمة المضمنة، كانت عناوين الكائنات تبدأ بشكل مطلق من موقع معروف، وغالبًا ما تكون صفرًا. نظرًا لأن أنظمة المعالجة المتعددة تربط وتتحول ديناميكيًا بين البرامج، أصبح من الضروري أن تكون قادرًا على نقل الكائنات باستخدام رمز مستقل عن الموضع. عادةً ما يقوم الرابط بإجراء إعادة التوطين جنبًا إلى جنب مع دقة الرمز، وعملية البحث عن الملفات والمكتبات لاستبدال المراجع الرمزية أو أسماء المكتبات بعناوين فعلية قابلة للاستخدام في الذاكرة قبل تشغيل البرنامج.

ويتم نقل عادة عن طريق رابط في وقت الارتباط، ولكن يمكن أيضا أن يتم ذلك في وقت التحميل من قبل الانتقال محمل، أو في وقت التشغيل من قبل برنامج تشغيل نفسه. تتجنب بعض الأبنية النقل تمامًا عن طريق تأجيل تعيين العنوان لوقت التشغيل؛ يُعرف هذا باسم حساب العنوان الصفري.

تجزئة

تُقسم ملفات الكائنات إلى أنواع مختلفة من مقاطع الذاكرة. تتضمن مقاطع المثال مقطع الكود (نص.)، مقطع بيانات مهيأ (بيانات.)، مقطع بيانات غير مهيأ (.bss)، أو غير ذلك.

جدول النقل

جدول النقل هو قائمة بالمؤشرات التي أنشأها المترجم (مترجم أو مُجمّع) وخُزِّنَتْ في الكائن أو الملف القابل للتنفيذ. كل إدخال في الجدول، أو "إصلاح"، هو مؤشر لعنوان مطلق في رمز الكائن الذي يجب تغييره عندما يقوم المُحمل بتغيير موقع البرنامج بحيث يشير إلى الموقع الصحيح. صُمِّمَ Fixups لدعم نقل البرنامج كوحدة كاملة. في بعض الحالات، يكون كل إصلاح في الجدول هو نفسه متعلقًا بالعنوان الأساسي صفر، لذلك يجب تغيير الإصلاحات نفسها أثناء تحرك أداة التحميل عبر الجدول.

في بعض البنى، يعد الإصلاح الذي يتجاوز حدودًا معينة (مثل حدود المقطع) أو الذي لا يتم محاذاته على حدود الكلمة غير قانوني ويتم تمييزه كخطأ بواسطة الرابط.

دوز وا وندوز 16 بت

المؤشرات البعيدة (مؤشرات 32 بت مع مقطع: الإزاحة، تُستخدم لمعالجة مساحة ذاكرة 20 بت 640 كيلوبايت المتاحة لبرامج DOS)، والتي تشير إلى رمز أو بيانات داخل DOS قابل للتنفيذ (EXE)، لا تحتوي على مقاطع مطلقة، لأن يعتمد العنوان الفعلي للرمز / البيانات على مكان تحميل البرنامج في الذاكرة وهذا غير معروف حتى يتم تحميل البرنامج.

بدلاً من ذلك، المقاطع هي القيم النسبية في ملف DOS EXE. يجب تصحيح هذه الأجزاء، عندما يتم تحميل الملف القابل للتنفيذ في الذاكرة. يستخدم محمل EXE جدول نقل للعثور على الأجزاء التي تحتاج إلى تعديل.

ويندوز 32 بت

مع أنظمة تشغيل وندوز 32 بت، ليس من الضروري توفير جداول إعادة تحديد موقع لملفات EXE، نظرًا لأنها أول صورة يتم تحميلها في مساحة العنوان الافتراضية، وبالتالي سيتم تحميلها على العنوان الأساسي المفضل لديهم.

بالنسبة إلى كل من مكتبات DLL و EXE التي تشترك في التوزيع العشوائي لتخطيط مساحة العنوان (ASLR) - وهي تقنية لتخفيف الاستغلال تم تقديمها مع نظام التشغيل وندوز فيستا، تصبح جداول إعادة التوطين مرة أخرى إلزامية نظرًا لاحتمال نقل الملف الثنائي ديناميكيًا قبل تنفيذه، على الرغم من أنها لا يزال أول شيء يتم تحميله في مساحة العنوان الافتراضية.

نظام التشغيل وندوز 64 بت

عند تشغيل ثنائيات 64 بت أصلية على نظام التشغيل وندوز فيستا والإصدارات الأحدث، فإن ASLR إلزامي، وبالتالي لا يمكن حذف أقسام النقل من قبل المترجم.

أنظمة شبيهة بيونكس

يسمح التنسيق القابل للتنفيذ والصيغة القابلة للربط (ELF) وتنسيق المكتبة المشتركة الذي تستخدمه معظم الأنظمة الشبيهة بيونكس بتحديد عدة أنواع من إعادة التوطين.

إجراء النقل

يقرأ الرابط معلومات المقطع وجداول النقل في ملفات الكائنات وينفذ عملية النقل عن طريق:

• دمج جميع الأجزاء من النوع الشائع في جزء واحد من هذا النوع
• تعيين عناوين وقت تشغيل فريدة لكل قسم وكل رمز، مع إعطاء جميع التعليمات البرمجية (الوظائف) والبيانات (المتغيرات العامة) عناوين وقت تشغيل فريدة 
• بالإشارة إلى جدول النقل للتعديل الرموز بحيث تشير إلى الصحيح عناوين وقت التشغيل.

مثال

يستخدم المثال التالي بنية مكس ولغة التجميع مكسال الخاصة بدونالد كانوت المبادئ هي نفسها لأي بنية، رغم أن التفاصيل ستتغير.

• (أ) يتم تجميع برنامج SUBR لإنتاج ملف كائن (B)، يظهر ككود الجهاز والمجمع. قد يبدأ المترجم الشفرة المترجمة في موقع عشوائي، وغالبًا ما يكون الموقع 1 كما هو موضح. يحتوي الموقع 13 على رمز الآلة لتعليمات الانتقال إلى العبارة ST في الموقع 5.
• (ج) إذا تم ربط SUBR لاحقًا برمز آخر، فقد يتم تخزينه في مكان آخر غير 1. في هذا المثال، يضعه الرابط في الموقع 120. يجب نقل العنوان في تعليمات القفز، والتي هي الآن في موقع 133، للإشارة إلى الموقع الجديد من رمز للبيان ST، الآن 125. [1 61 هو مبين في التعليمات هي رمز الجهاز تمثيل MIX 125].
• (د) عند تحميل البرنامج في الذاكرة لتشغيله، يمكن تحميله في مكان آخر غير الموقع المعين من قبل الرابط. يوضح هذا المثال SUBR الآن في الموقع 300. يحتاج العنوان الموجود في تعليمات الانتقال، الآن في 313، إلى إعادة نقله مرة أخرى بحيث يشير إلى الموقع المحدث لـ ST 305. [4 49 هو تمثيل آلة MIX لـ 305].

انظر أيضًا

• الرابط (الحوسبة)
• المكتبة (الحوسبة)
• ملف الكائن
• جمع القمامة

مواضيع ذات صلة

• 11/34 Memory Management Basic Logic test، ديجيتال إكوبمينت (DEC)، 21 ديسمبر 1975 [1975-11-13]، MAINDEC-11-DFKTA-A-D، اطلع عليه بتاريخ 2017-08-19
• "A simple technique for static relocation of absolute machine code". People's Computer Company. ج. 3 ع. 2: 10–13 (66–69). فبراير 1978. ISBN:0-8104-5490-4. #22. مؤرشف من الأصل في 2017-09-09. اطلع عليه بتاريخ 2017-08-19. [1] [2] [3] (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 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).)
• Huitt، Robert (25 أبريل 2014). Laws (المحرر). "Legacy of Gary Kildall: The CP/M IEEE Milestone Dedication" (PDF) (video transscription). متحف تاريخ الحاسوب. CHM Reference number: X7170.2014. مؤرشف من الأصل (PDF) في 2014-12-27. اطلع عليه بتاريخ 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 ترتيب البايتات. 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 سي بي / م 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. […] إنتل […] had the ترتيب البايتات, 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 […] [4][5] (33 pages)
• "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". Heise Verlag (part 1) (بالألمانية). 1987 (1): 124–135. 1987; "CP/M 2 lernt dazu. Modulare Systemerweiterungen auch für das 'alte' CP/M". Heise Verlag (part 2) (بالألمانية). 1987 (2): 78–85. 1987; Huck, Alex (9 Oct 2016). "RSM für CP/M 2.2". Homecomputer DDR (بالألمانية). Archived from the original on 2016-11-25. Retrieved 2016-11-25.
• Guzis، Charles "Chuck" P. (16 مارس 2015). "Re: CP/M assembly language programming". Vintage Computer Forum. Genre: CP/M and MP/M. مؤرشف من الأصل في 2020-02-01. اطلع عليه بتاريخ 2020-02-01. […] Ever wonder how MOVCPM works? Since the سي بي / م 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 حيد 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. (29 يوليو 2015). "Re: How does MOVCPM.COM work?". Vintage Computer Forum. Genre: CP/M and MP/M. مؤرشف من الأصل في 2020-02-01. اطلع عليه بتاريخ 2020-02-01. […] MOVCPM uses an early type of PRL format. Basically, سي بي / م 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 ترتيب البايتات of an address is to be adjusted. Low order address bytes are not affected; hence, "Page relocatble 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. (8 نوفمبر 2016). "Re: Is it safe to use RST 28h in CP/M assembly programs?". Vintage Computer Forum. Genre: CP/M and MP/M. مؤرشف من الأصل في 2020-02-01. اطلع عليه بتاريخ 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 سي بي / م. 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 معالج زد 80 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 وقت التنفيذ 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. […]
• "Relocation Is Not Just Moving Programs". People's Computer Company. Ridgefield, CA, USA. ج. 3 ع. 2: 14–20 (70–76). فبراير 1978 [1977]. ISBN:0-8104-5490-4. #22. مؤرشف من الأصل في 2019-04-20. اطلع عليه بتاريخ 2019-04-19.
• Calingaert، Peter (1979) [1978-11-05]. "8.2.2 Relocating Loader". كتب في جامعة ولاية كارولينا الشمالية في تشابل هيل. في Horowitz (المحرر). Assemblers, Compilers, and Program Translation. Computer software engineering series (ط. 1st printing, 1st). Potomac, Maryland, USA: Computer Science Press, Inc. ص. 237–241. ISBN:0-914894-23-4. ISSN:0888-2088. LCCN:78-21905. اطلع عليه بتاريخ 2020-03-20. (2+xiv+270+6 pages)
• The Microsoft OBJ File Format. مايكروسوفت, Product Support Services. Application Note SS0288. مؤرشف من الأصل في 2017-09-09. اطلع عليه بتاريخ 2017-08-21.
• Tanenbaum، Andrew Stuart؛ Bos، Herbert (2015). Modern Operating Systems (ط. 4). تعليم بيرسون. ISBN:978-0-13359162-0.
• Elliott، John C. (5 يونيو 2012) [2000-01-02]. "PRL file format". seasip.info. مؤرشف من الأصل في 2020-01-26. اطلع عليه بتاريخ 2020-01-26. […] A PRL file is a relocatable binary file, used by MP/M and سي بي / م for various modules other than .COM files. The file format is also used for FID files on the أمستراد بي سي دبليو. 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 سي بي / مs (.RSX). […] [6]
• Elliott، John C. (5 يونيو 2012) [2000-01-02]. "Microsoft REL format". seasip.info. مؤرشف من الأصل في 2020-01-26. اطلع عليه بتاريخ 2020-01-26. […] The REL format is generated by مايكروسوفت's M80 and Digital Research's RMAC. […]
• feilipu (5 سبتمبر 2018) [2018-09-02]. "Support for PRL, page relocatable executable for MP/M". z88dk. مؤرشف من الأصل في 2020-02-01. اطلع عليه بتاريخ 2020-01-26. […] Out of the assembled مايكروسوفت.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. […]
• "Understanding Relocatable Code". 1001001, Inc. The Next Step ع. 39: 38, 40, 42, 45. أبريل 1983. ISSN:0744-7868. اطلع عليه بتاريخ 2020-02-06. [7][8]
• "Relocatable Programs: Microcomputing's Hoboes". CW Communications/Peterborough, Inc. The Next Step ع. 63: 98, 100, 102–103. أبريل 1985. ISSN:0744-7868. اطلع عليه بتاريخ 2020-02-06. [9][10]
• "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. يوليو–أغسطس 1988. ISSN:0748-9331. ark:/13960/t36121780. اطلع عليه بتاريخ 2020-02-09. [11][12]
• "ZCPR3 Corner - More on relocatable code, PRL files, ZCPR34, and Type-4 programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Advanced CP/M. Columbia Falls, Montana, USA ع. 34: 20–25. سبتمبر–أكتوبر 1988. ISSN:0748-9331. ark:/13960/t0ks7pc39. اطلع عليه بتاريخ 2020-02-09. [13][14]
• "Writing Relocatable Code - Some embedded code must run at more than one address". The Ganssle Group - Perfecting the Art of Building Embedded Systems / TGG. فبراير 1992. مؤرشف من الأصل في 2019-07-18. اطلع عليه بتاريخ 2020-02-20.