ओवरले (प्रोग्रामिंग)

From Vigyanwiki
Not to be confused with ओवरलोड (प्रोग्रामिंग), निष्पादन (प्रणाली कॉल), ओवरलैपिंग कोड, or साझा कोड.
ढांच के रूप में

एक सामान्य कंप्यूटिंग अर्थ में, ओवरलेइंग का अर्थ प्रोग्राम कोड या अन्य डेटा के ब्लॉक (डेटा संचय) को मुख्य मेमोरी में स्थानांतरित करने की प्रक्रिया है, जो पहले से ही संग्रहीत है।[1]ओवरलेइंग एक कंप्यूटर प्रोग्रामिंग पद्धति है जो प्रोग्राम को कंप्यूटर की मुख्य मेमोरी से बड़ा होने की अनुमति देती है।[2] भौतिक मेमोरी की सीमा के कारण एक एम्बेडेड प्रणाली सामान्य रूप से ओवरले का उपयोग करेगा, जो कि चिप पर प्रणाली के लिए आंतरिक मेमोरी है, और आभासी मेमोरी सुविधाओं की कमी है।

उपयोग

ओवरले प्रोग्राम के निर्माण में मैन्युअल रूप से एक प्रोग्राम को स्व-निहित वस्तु कोड ब्लॉक में विभाजित करना सम्मिलित है, जिसे ओवरले या लिंक कहा जाता है, जिसे सामान्यतः ट्री संरचना में रखा जाता है।[lower-alpha 2] सिबलिंग सेगमेंट जो समान गहराई के स्तर पर ओवरले क्षेत्र या गंतव्य क्षेत्र नामक समान मेमोरी साझा करते हैं।[lower-alpha 3] एक ओवरले प्रबंधक, ऑपरेटिंग प्रणाली का भाग या ओवरले प्रोग्राम का भाग, आवश्यक ओवरले को सहायक मेमोरी से अपने गंतव्य क्षेत्र में लोड करता है जब इसकी आवश्यकता होती है; यह स्वचालित या स्पष्ट कोड के माध्यम से हो सकता है। अधिकांश लिंकर (कंप्यूटिंग) ओवरले के लिए सहायता प्रदान करते हैं।[3]


उदाहरण

निम्न उदाहरण उन नियंत्रण कथनों को दिखाता है जो OS/360 लिंकेज संपादक को संरचना दिखाने के लिए इंडेंट किए गए एकल क्षेत्र वाले ओवरले प्रोग्राम को लिंक करने का निर्देश देते हैं (खंड नाम मनमाने हैं):

INCLUDE SYSLIB(MOD1)
 INCLUDE SYSLIB(MOD2)
 OVERLAY A
   INCLUDE SYSLIB(MOD3)
     OVERLAY AA
       INCLUDE SYSLIB(MOD4)
       INCLUDE SYSLIB(MOD5)
     OVERLAY AB
        INCLUDE SYSLIB(MOD6)
 OVERLAY B
    INCLUDE SYSLIB(MOD7)

  +--------------+
                       | Root Segment |
                       | MOD1, MOD2   |
                       +--------------+
                               |
                    +----------+----------+
                    |                     |
             +-------------+       +-------------+
             |  Overlay A  |       |  Overlay B  |
             |  MOD3       |       |  MOD7       |
             +-------------+       +-------------+
                    |
           +--------+--------+
           |                 |
    +-------------+   +-------------+
    | Overlay AA  |   | Overlay AB  |
    | MOD4, MOD5  |   | MOD6        |
    +-------------+   +-------------+

ये कथन स्थायी रूप से निवासी खंड, जिसे रूट कहा जाता है, और दो ओवरले A और B से मिलकर एक पेड़ को परिभाषित करता है जो MOD2 के अंत के बाद लोड किया जाएगा। ओवरले A में स्वयं दो ओवरले सेगमेंट, AA और AB होते हैं। निष्पादन के समय ओवरले A और B दोनों समान मेमोरी स्थानों का उपयोग करेंगे; AA और AB दोनों MOD3 के अंत के बाद एक ही स्थान का उपयोग करेंगे।

रूट और दिए गए ओवरले सेगमेंट के बीच के सभी सेगमेंट को पाथ कहा जाता है।

अनुप्रयोग

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

एम्बेडेड प्रणाली में अभी भी ओवरले उपयोगी हैं।[4] एम्बेडेड प्रणालियाँ में उपयोग किए जाने वाले कुछ कम लागत वाले प्रोसेसर मेमोरी मैनेजमेंट यूनिट (एमएमयू) प्रदान नहीं करते हैं। इसके अतिरिक्त कई एम्बेडेड प्रणाली रीयल-टाइम कंप्यूटिंग प्रणाली हैं और ओवरले पेजिंग की तुलना में अधिक निर्धारित प्रतिक्रिया-समय प्रदान करते हैं उदाहरण के लिए, स्पेस शटल प्राइमरी एवियोनिक्स प्रणाली सॉफ़्टवेयर (पास) प्रोग्राम किए गए ओवरले का उपयोग करता है।[5]

कोडेक्स युग्मन (कंप्यूटर विज्ञान) जैसे वर्चुअल मेमोरी सॉफ्टवेयर घटकों वाले प्लेटफ़ॉर्म पर भी उस बिंदु पर डिकॉय किया जा सकता है जहां उन्हें आवश्यकतानुसार लोड और आउट किया जा सकता है।

ऐतिहासिक उपयोग

आईबीएम ने फोरट्रान द्वितीय में चेन जॉब की अवधारणा प्रस्तुत की।[6] प्रोग्राम को एक नया लिंक लोड करने के लिए चेन सबरूटीन को स्पष्ट रूप से कॉल करना पड़ा, और नए लिंक ने फोरट्रान कॉमन क्षेत्र को छोड़कर पुराने लिंक के सभी संचय को बदल दिया।

आईबीएम ने IBSYS/IBJOB में अधिक सामान्य ओवरले हैंडलिंग की प्रारंभ की[7] जिसमें कॉल प्रोसेसिंग के भाग के रूप में पेड़ की संरचना और लिंक की स्वत: लोडिंग सम्मिलित है।

OS/360 में, आईबीएम ने आईबीएलडीआर की ओवरले सुविधा को एक ओवरले प्रोग्राम को अपने स्वयं के ओवरले ट्री के साथ प्रत्येक स्वतंत्र ओवरले क्षेत्र की अनुमति देकर बढ़ाया। ओएस/360 में 1024-बाइट एसवीसी क्षणिक क्षेत्रों का उपयोग करते हुए क्षणिक पर्यवेक्षक कॉल रूटीन के लिए एक सरल ओवरले प्रणाली भी था। होम कम्प्यूटर युग में ओवरले लोकप्रिय थे क्योंकि ऑपरेटिंग प्रणाली और इसके चलने वाले कई कंप्यूटर प्रणाली में वर्चुअल मेमोरी की कमी थी और वर्तमान मानकों के अनुसार बहुत कम रैम थी: कॉन्फ़िगरेशन के आधार पर मूल आईबीएम पीसी में 16K और 64K के बीच था। ग्राफिक्स स्क्रीन लोड करने के लिए कमोडोर बेसिक में ओवरले एक लोकप्रिय विधि थी।[2]

1980 के दशक में कई डॉस लिंकर्स ने [ओवरले] को एक ऐसे रूप में समर्थित किया जो लगभग 25 साल पहले मेनफ्रेम कंप्यूटर पर उपयोग किए जाने वाले फॉर्म के समान था।[4][8] मेमोरी ओवरले वाली बाइनरी फ़ाइलों में वास्तविक मानक एक्सटेंशन .OVL[8] या .OVR[9](किन्तु बाद की फ़ाइलों के लिए संख्यात्मक फ़ाइल एक्सटेंशन जैसे .000, .001, आदि का भी उपयोग किया जाता है[10]) थे। इस फ़ाइल प्रकार का उपयोग दूसरों के बीच वर्डस्टार[11](मुख्य निष्पादन योग्य से मिलकर WS.COM और ओवरले मॉड्यूल WSMSGS.OVR, WSOVLY1.OVR, MAILMERGE.OVR और SPELSTAR.OVR, जहां वसा बाइनरी ओवरले फ़ाइलें CP/M-86 और एमएस-डॉस के लिए उनके बंदरगाहों में बाइनरी समान थीं[12]), dBase,[13] और सक्षम सॉफ्टवेयर (कंपनी) से सक्षम (ऑफिस सूट) डॉस ऑफिस स्वचालन सॉफ्टवेयर पैकेज द्वारा किया गया था। बोरलैंड का टर्बो पास्कल[14][15] और जीएफए बेसिक कंपाइलर .OVL फाइलें बनाने में सक्षम थे।

यह भी देखें

टिप्पणियाँ

  1. ↑ This has nothing to do with the term region in MVT storage management.
  2. ↑ In OS/360 and successors, there may be multiple regions[lower-alpha 1] each containing a complete overlay tree.
  3. ↑ The nomenclature varies depending on the system, e.g., in OS/360 region refers to an entire overlay tree.


संदर्भ

  1. ↑ "Oxford Dictionaries". 2015-11-26. Archived from the original on 2022-07-10. Retrieved 2022-07-10.
  2. ↑ 2.0 2.1 Butterfield, James "Jim", ed. (June 1986). "Part 4: Overlaying". Loading And Linking Commodore Programs. p. 74. Archived from the original on 2022-07-10. Retrieved 2022-07-10. This lets you run programs which are, in effect, much larger than the amount of memory in your computer. {{cite book}}: |magazine= ignored (help)
  3. ↑ 4.0 4.1 Levine, John R. (2000). Linkers & Loaders. Morgan Kaufmann Publishers. p. 177. ISBN 1-55860-496-0. Archived from the original on 2022-04-06. Retrieved 2022-07-10. [2]
  4. ↑ National Research Council (November 1993) [June 1993]. An Assessment of Space Shuttle Flight Software Development Processes (2 ed.). Washington, DC, USA: National Academy of Sciences, The National Academies Press. doi:10.17226/2222. hdl:2060/19930019745. ISBN 978-0-309-04880-4. LCCN 93-84549. Retrieved 2012-10-29. (208 pages)
  5. ↑ "Chapter 12: The Chain Job" (PDF). IBM 7090/7094 Programming Systems – FORTRAN II Programming (PDF). August 1963. pp. 34–35. Form C28-6054-4 File No. 7090-25. Archived (PDF) from the original on 2022-03-15. Retrieved 2022-07-10. {{cite book}}: |work= ignored (help) (52 pages)
  6. ↑ IBM 7090/7094 Programming Systems – IBJOB Processor – Overlay feature of IBLDR (PDF). May 1963. Form C28-6331 File No. 7090-27. Archived (PDF) from the original on 2022-03-15. Retrieved 2021-12-26. {{cite book}}: |work= ignored (help) (8 pages)
  7. ↑ 8.0 8.1 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). […] [3]
  8. ↑ Dohmen, Norbert (1990). "Platz schaffen durch Überlagern - Overlay-Strukturen in Turbo Pascal". mc (in Deutsch). Vol. 90, no. 12. pp. 124–130. Archived from the original on 2022-08-04. Retrieved 2022-08-04. [4]
  9. ↑ Gavin, Bruce. "Create Program Overlays". In Pearson, Dave (ed.). Turbo Pascal - Norton Guide. v3. p. 149. Archived from the original on 2022-08-04. Retrieved 2022-08-04.
  10. ↑ Mabbett, Alan (1985). Getting started with WordStar, MailMerge + SpellStar. Cambridge University Press. ISBN 0-521-31805-X.
  11. ↑ Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. "WordStar Again". OS/2 Museum. Archived from the original on 2019-07-28. Retrieved 2019-07-28. […] The reason to suspect such difference is that version 3.2x also supported CP/M-86 (the overlays are identical between DOS and CP/M-86, only the main executable is different) […] the .OVR files are 100% identical between DOS and CP/M-86, with a flag (clearly shown in the WordStar 3.20 manual) switching between them at runtime […] the OS interface in WordStar is quite narrow and well abstracted […] the WordStar 3.2x overlays are 100% identical between the DOS and CP/M-86 versions. There is a runtime switch which chooses between calling INT 21h (DOS) and INT E0h (CP/M-86). WS.COM is not the same between DOS and CP/M-86, although it's probably not very different either. […]
  12. ↑ Sidnam-Wright, Liz; Stevens, Brad, eds. (1990-07-31). "Ashton-Tate ships dBASE IV Version 1.1" (PDF). Torrance, California, USA: Ashton Tate. p. 2-2-2. Archived from the original (PDF) on 2017-04-04. Retrieved 2014-02-13. Version 1.1 has a new dynamic Memory Management System (dMMS) that handles overlays more efficiently: the product requires less memory, which results in more applications space availability. […] The product's lower memory requirements of only 450K of RAM provide improved network support because supplemental hardware memory is no longer required to support networks. […] By speeding up areas of dBASE IV that are overlay-dependent, the new dMMS improves performance when working at the Control Center and in programs that use menus and windows. (5 pages)
  13. ↑ Herschel, Rudolf; Dieterich, Ernst-Wolfgang (2000). Turbo Pascal 7.0 (in Deutsch) (2 ed.). R. Oldenbourg Verlag [de]. p. 249. ISBN 3-486-25499-5.
  14. ↑ Eßer, Hans-Georg (June 2009). "Chapter 6. Speicherverwaltung und Dateisysteme - Teil 5: Nicht-zusammenhängende Speicherzuordnung". Betriebssysteme I (PDF) (in Deutsch). Munich, Germany: Hochschule München. Archived (PDF) from the original on 2022-05-08. Retrieved 2014-02-13. (9 pages)


अग्रिम पठन

  • IBM OS Linkage Editor and Loader - Program Numbers 360S-ED-510, 360S-ED-521, 360S-LD-547 (PDF). March 1972 [January 1972]. Order No. GC28-6538-9, File No. S360-31. Archived (PDF) from the original on 2022-07-10. {{cite book}}: |work= ignored (help) (2+244+4 pages)
  • Groeber, Marcus; Di Geronimo, Jr., Edward "Ed"; Paul, Matthias R. (2002-03-02) [2002-02-24]. "GEOS/NDO info for RBIL62?". Newsgroup: comp.os.geos.programmer. Archived from the original on 2019-04-20. Retrieved 2019-04-20. […] The reason Geos needs 16 interrupts is because the scheme is used to convert inter-segment ("far") function calls into interrupts, without changing the size of the code. The reason this is done so that "something" (the kernel) can hook itself into every inter-segment call made by a Geos application and make sure that the proper code segments are loaded from virtual memory and locked down. In DOS terms, this would be comparable to an overlay loader, but one that can be added without requiring explicit support from the compiler or the application. What happens is something like this: […] 1. The real mode compiler generates an instruction like this: CALL <segment>:<offset> -> 9A <offlow><offhigh><seglow><seghigh> with <seglow><seghigh> normally being defined as an address that must be fixed up at load time depending on the address where the code has been placed. […] 2. The Geos linker turns this into something else: INT 8xh -> CD 8x […] DB <seghigh>,<offlow>,<offhigh> […] Note that this is again five bytes, so it can be fixed up "in place". Now the problem is that an interrupt requires two bytes, while a CALL FAR instruction only needs one. As a result, the 32-bit vector (<seg><ofs>) must be compressed into 24 bits. […] This is achieved by two things: First, the <seg> address is encoded as a "handle" to the segment, whose lowest nibble is always zero. This saves four bits. In addition […] the remaining four bits go into the low nibble of the interrupt vector, thus creating anything from INT 80h to 8Fh. […] The interrupt handler for all those vectors is the same. It will "unpack" the address from the three-and-a-half byte notation, look up the absolute address of the segment, and forward the call, after having done its virtual memory loading thing... Return from the call will also pass through the corresponding unlocking code. […] The low nibble of the interrupt vector (80h–8Fh) holds bit 4 through 7 of the segment handle. Bit 0 to 3 of a segment handle are (by definition of a Geos handle) always 0. […] all Geos API run through the "overlay" scheme […]: when a Geos application is loaded into memory, the loader will automatically replace calls to functions in the system libraries by the corresponding INT-based calls. Anyway, these are not constant, but depend on the handle assigned to the library's code segment. […] Geos was originally intended to be converted to protected mode very early on […], with real mode only being a "legacy option" […] almost every single line of assembly code is ready for it […]


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=ओवरले_(प्रोग्रामिंग)&oldid=195238’