오버레이(프로그래밍)

Overlay (programming)
오버로드(프로그래밍), Exec(시스템콜), 오버랩 코드 또는 공유 코드와 혼동하지 마십시오.
개략도

일반적인 컴퓨팅의 의미에서 오버레이는 "프로그램 코드 또는 다른 데이터의 블록을 메인 메모리에 전송하여 이미 저장되어 있는 것을 대체하는 과정"[1]을 의미한다.오버레이는 프로그램을 컴퓨터의 메인 [2]메모리보다 크게 하는 프로그래밍 방법입니다.임베디드 시스템에서는 일반적으로 시스템 온칩의 내장 메모리인 물리 메모리의 제한과 가상 메모리 설비의 부족 때문에 오버레이를 사용합니다.

사용.

오버레이 프로그램을 구축하려면 프로그램을 오버레이 또는 링크라고 하는 독립 객체 코드 블록으로 수동으로 분할해야 하며 일반적으로 트리 [b]구조로 배치됩니다.형제 세그먼트(같은 깊이 레벨에 있는 세그먼트)는, 오버레이[c] 영역 또는 대상 영역이라고 하는 같은 메모리를 공유합니다.운영 체제의 일부 또는 오버레이 프로그램의 일부인 오버레이 관리자는 필요할 때 필요한 오버레이를 외부 메모리에서 대상 영역으로 로드합니다. 이 오버레이는 자동 또는 명시적 코드를 통해 로드됩니다.링커는 오버레이를 [3]지원하는 경우가 많습니다.

예

다음으로 OS/360 Link Editor에 단일 영역을 포함하는 오버레이 프로그램을 링크하도록 지시하는 제어문의 예를 나타냅니다(세그먼트 이름은 임의). 

인크루드 SYSLIB(MOD1) 오버레이 A 인크루드 SYSLIB(MOD3) 오버레이 AA 인크루드 SYSLIB(MOD4) 오버레이 AB 인크루드 SYSLIB(MOD6) 오버레이 B 인크루드 SYSLIB(7)
+-----------------+ 루트 세그먼트 MOD1, MOD2 +-----------+ +---------+ +---------+ +-------+ Overlay A 오버레이 B MOD3 MOD7 +---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+   +-------------+

이러한 문장은 루트라고 하는 영구 상주 세그먼트와 MOD2 종료 후에 로드되는 두 개의 오버레이 A 및 B로 구성된 트리를 정의합니다.오버레이 A 자체는 2개의 오버레이 세그먼트(AA 및 AB)로 구성됩니다.실행 시 오버레이 A와 B는 모두 동일한 메모리 위치를 사용하고, AA와 AB는 모두 MOD3의 종료 후에 동일한 위치를 사용합니다.

루트와 지정된 오버레이 세그먼트 사이의 모든 세그먼트를 경로라고 합니다.

적용들

2015년 현재 대부분의 비즈니스 애플리케이션은 가상 메모리가 있는 플랫폼에서 실행되도록 설계되었습니다.이러한 플랫폼의 개발자는 프로그램의 작업 세트가 사용 가능한 물리적 메모리를 초과하지 않는 한 메모리 제약이 존재하지 않는 것처럼 프로그램을 설계할 수 있다.가장 중요한 것은 설계자가 오버레이 크기에 의해 제약을 받는 단계를 강제하는 설계상의 어려움 없이 해결되는 문제에 집중할 수 있다는 것입니다.따라서 설계자는 프로그래머가 크기를 많이 제어할 수 없는 고급 프로그래밍 언어(예: Java, C++, Smalltalk)를 사용할 수 있습니다.

그러나 임베디드 [4]시스템에서 오버레이는 여전히 유용합니다.임베디드 시스템에 사용되는 저가 프로세서 중에는 메모리 관리 유닛(MMU)이 없는 것이 있습니다.또한 많은 임베디드 시스템은 실시간 시스템이며 오버레이는 페이징보다 더 확실한 응답 시간을 제공합니다.예를 들어, Space Shuttle Primary Avionics System Software(PASS)는 프로그래밍된 [5]오버레이를 사용합니다.

가상 메모리를 탑재한 플랫폼에서도 코덱 등의 소프트웨어 컴포넌트는 필요에 따라 로딩하거나 로딩할 수 있을 정도로 분리될 수 있습니다.

이력 사용

IBM은 FORTRAN II에서 체인[6] 작업의 개념을 도입했습니다.프로그램은 새 링크를 로드하기 위해 CHANE 서브루틴을 명시적으로 호출해야 했고, 새 링크는 Fortran COMMON 영역을 제외한 모든 오래된 링크의 스토리지를 대체했습니다.

IBM은 IBSYS/IBJOB에서 CALL 처리의 일부로 트리 구조 및 링크 자동 로드를 포함한 보다 일반적인 오버레이[7] 처리를 도입했습니다.

OS/360에서 IBM은 오버레이 프로그램에 각각 자체 오버레이 트리가 있는 독립적인 오버레이 영역을 허용함으로써 IBLDR의 오버레이 기능을 확장했습니다.OS/360은 또한 1024바이트의 SVC 과도 영역을 사용하여 과도 SVC 루틴을 위한 더 단순한 오버레이 시스템을 가지고 있었다.

가정용 컴퓨터 시대에는 운영 체제와 운영 체제에서 실행되는 많은 컴퓨터 시스템이 가상 메모리가 부족하고 RAM이 매우 적었기 때문에 오버레이가 유행했습니다. 원래의 IBM PC는 구성에 따라 16K에서 64K 사이였습니다.오버레이는 Commodore BASIC에서 그래픽 [2]화면을 로드하는 데 널리 사용되는 기술입니다.

"1980년대 몇몇 DOS 링커는 25년 전에 메인프레임 컴퓨터에서 사용되던 것과 거의 동일한 형태로 지원되었습니다.메모리 오버레이를 포함한 바이너리 파일에는 사실상의 표준 확장자가 붙어 있었습니다.[4][8]OVL[8] 또는OVR[9](단[10], 후속 파일에는 .000, .001 등의 숫자 파일 확장자를 사용).이 파일 형식은 WordStar(주 실행 파일 구성)에서[11] 사용되었습니다.WS.COM및 오버레이 모듈WSMSGS.OVR,WSOVLY1.OVR,MAILMERGE.OVR그리고.SPELSTAR.OVR여기서 "팻" 오버레이 파일은 CP[12]/M-86 및 MS-DOS용 포트에서 바이너리까지 동일했습니다.dBase [13]및 Enable Software의 Enable DOS Office Automation 소프트웨어 패키지가 있습니다.Borland의[14][15] Turbo Pascal과 GFA BASIC 컴파일러는 을 생산할 수 있었다.OVL 파일

「 」를 참조해 주세요.

메모들

  1. ^ 이는 MVT 스토리지 관리의 영역이라는 용어와 무관합니다.
  2. ^ OS/360 및 후속 버전에서는 각각 완전한 오버레이 트리를 포함하는 여러 영역이[a] 있을 수 있습니다.
  3. ^ 명명법은 시스템에 따라 다릅니다.예를 들어 OS/360 지역에서는 오버레이 트리 전체를 나타냅니다.

레퍼런스

  1. ^ "Oxford Dictionaries". 2015-11-26. Archived from the original on 2022-07-10. Retrieved 2022-07-10.
  2. ^ a b Butterfield, James "Jim", ed. (June 1986). "Part 4: Overlaying". Loading And Linking Commodore Programs. Compute!. 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.
  3. ^ a b 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. ISBN 978-0-309-04880-4. LCCN 93-84549. Retrieved 2012-10-29. (104 페이지)
  5. ^ "Chapter 12: The Chain Job" (PDF). IBM 7090/7094 Programming Systems – FORTRAN II Programming (PDF). Systems Reference Library. Poughkeepsie, New York, USA: IBM Corporation. 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. (52페이지)
  6. ^ IBM 7090/7094 Programming Systems – IBJOB Processor – Overlay feature of IBLDR (PDF). Systems Reference Library (1 ed.). Poughkeepsie, New York, USA: IBM Corporation. May 1963. Form C28-6331 File No. 7090-27. Archived (PDF) from the original on 2022-03-15. Retrieved 2021-12-26. (8페이지)
  7. ^ a b 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 German). 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, 리즈, 스티븐스, 브래드, eds.(1990-07-31)."Ashton-Tate 배들 IV1.1dBASE"(PDF).캘리포니아 주, 미국:애슈턴 테이트. p. 2-2-2.2017-04-04에 있는 원본(PDF)에서 Archived.2014-02-13 Retrieved.1.1:제품은 더 많은 응용 프로그램은 공간 이용 가능성에 결과 더 적은 메모리를 필요로 하고는 더 효율적으로 오버레이를 처리하는 새롭고 동적 메모리 관리 시스템(dMMS)을 가지고 있다.때문에 추가 하드웨어 메모리 더 이상 네트워크를 지원할 필요하다만 450K 램을 개선한 네트워크 지원을 제공한다의 제품의 낮은 메모리 요구 사항[…].는 제어 센터와 메뉴 및 창의 사용하는 프로그램에서 일하는dBASE 4세의overlay-dependent 있는 지역이 더욱 가속화됨으로써[…], 새로운 dMMS의 성과를 향상시킨다.(5장)
  13. ^ Herschel, Rudolf; Dieterich, Ernst-Wolfgang (2000). Turbo Pascal 7.0 (in German) (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 German). Munich, Germany: Hochschule München. Archived (PDF) from the original on 2022-05-08. Retrieved 2014-02-13. (9페이지)

추가 정보

  • IBM OS Linkage Editor and Loader - Program Numbers 360S-ED-510, 360S-ED-521, 360S-LD-547 (PDF). Systems Reference Library. Release 21 (10 ed.). White Plains, New York, USA: IBM Corporation. March 1972 [January 1972]. Order No. GC28-6538-9, File No. S360-31. Archived (PDF) from the original on 2022-07-10. (2+244+4페이지)
  • 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 […]

외부 링크