Content deleted Content added
Matthiaspaul (talk | contribs) →Further reading: +ref |
Matthiaspaul (talk | contribs) →Further reading: +refs |
||
Line 97:
* {{cite book |title=IBM OS Linkage Editor and Loader - Program Numbers 360S-ED-510, 360S-ED-521, 360S-LD-547 |id=Order No. GC28-6538-9, File No. S360-31 |version=Release 21 |date=March 1972 |orig-date=January 1972 |edition=10 |publisher=[[IBM Corporation]] |publication-place=White Plains, New York, USA |work=Systems Reference Library |url=http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6538-9_OS_Linkage_Editor_and_Loader_Release_21_Jan72.pdf |url-status=live |archive-url=https://web.archive.org/web/20220710205449/http://www.bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/GC28-6538-9_OS_Linkage_Editor_and_Loader_Release_21_Jan72.pdf |archive-date=2022-07-10}} (2+244+4 pages)
* {{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 [[relocation (computing)|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 (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 newsgroup |title=GEOS/NDO info for RBIL62? |author-first1=Marcus |author-last1=Groeber |author-first2=Edward "Ed" |author-last2=Di Geronimo, Jr. |author-first3=Matthias R. |author-last3=Paul |date=2002-03-02 |orig-date=2002-02-24 |newsgroup=comp.os.geos.programmer |url=https://groups.google.com/d/msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |access-date=2019-04-20 |url-status=live |archive-url=https://archive.today/20190420111421/https://groups.google.com/forum/%23!msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |archive-date=2019-04-20 |quote=[…] The reason [[PC/GEOS|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 addressing (x86)|<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 [[fat pointer|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 […]}}
* {{cite magazine |title=Platz schaffen durch Überlagern - Overlay-Strukturen in Turbo Pascal |language=de |author-first=Norbert |author-last=Dohmen |magazine=[[mc (magazine)|mc]] |issn= |publisher= |issue=12 |volume=90 |date=1990 |pages=124-130 |url=https://guru-home.dyndns.org/Overlay.html |access-date=2022-08-04 |url-status=live |archive-url=https://web.archive.org/web/20220804163634/https://guru-home.dyndns.org/Overlay.html |archive-date=2022-08-04}} [https://web.archive.org/web/20220804163948/https://guru-home.dyndns.org/Overlay/pdf/Overlay.pdf]
* {{cite book |chapter=Create Program Overlays |title=Turbo Pascal |version=v3 |author-first=Bruce |author-last=Gavin |editor-first=Dave |editor-last=Pearson |page=149 |url=http://www.x-hacker.org/ng/pascal/ng19519.html |access-date=2022-08-04 |url-status=live |archive-url=https://web.archive.org/web/20220804163703/http://www.x-hacker.org/ng/pascal/ng19519.html |archive-date=2022-08-04}}
[[Category:Virtual memory]]
| |||