c 1979 Xerox CorporationInter-Office MemorandumToDistributionDateOctober 1, 1979FromRoy LevinLocationPalo AltoSubjectMesa for Extended Memory AltosOrganizationPARC/CSL(version 5)XEROX Filed on: [Ivy]Doc>XMesa.bravo (and .press)XMesa is a version of the Mesa runtime system that can exploit in certain ways the extendedmemory option of the Alto II. This document describes the facilities provided by this system, itslimitations, and its compatibility with other current Mesa systems.Overview of XMesaXMesa uses the extended memory of an Alto II XM as additional swapping space for code. Thismeans that code and data need not co-exist in the primary 64K of memory. XMesa takes advantageof any available extra space automatically; standard Alto programs do not need to be modified torun with XMesa. XMesa does not simplify the task of managing data structures that are too largeto fit in 64K, but it does free (most of) the 64K primary address space for use by data. Because XMesa uses extra memory for code segments, it includes a page-level storage allocator forthe additional banks. Client programs may request storage in the additional banks by using thisallocator; the interface is public. XMesa provides primitive mechanisms to read and write words inextended memory and to copy blocks of data between banks of memory, but gives no otherassistance in accessing information in the extended memory. In particular, arbitrary use of LONGPOINTERs is not supported.Clients should understand that, while XMesa is interface-compatible with Mesa 5.0 the implementation of certain systemcomponents (e.g., the page-level memory allocator and segment swapper) has changed substantially. Client programs thatassume undocumented properties of these components do so at their peril. Information about incompatibilities in theimplementation appears later in this document.Compatibility with Mesa 5.0Considerable efforts have been made to ensure that XMesa is compatible with Mesa 5.0.Exceptions are minor and typically affect only those programs that depend upon the format ofglobal frames (details appear below). To enhance the value of compatibility and because wide-bodied Altos are not universally available, XMesa will execute properly (though with someperformance degradation) on a normal Alto (I or II) without recompilation or rebinding. Indeed,XMesa requires no special compiler or binder. Both BCDs and image files are compatible acrossmachines. Thus a Mesa disk containing the XMesa versions of XMesa.image (orBasicXMesa.image), and the debugger can be used without alteration on any Alto, XM orotherwise. Specifically,Н%ОpqТXН]Оg~rТiНІОcsН]qН-єsН7BqТXНІО]ЭsН]qН-єsН7BqНІОYsН]qН-єsН7BqН]ОW│ НЭОSЛtqНЇОN"sТFП2НЇОG╗qТиПRТйНЇОFТ╒ТёПDНЇОDXТПCНЇО@5uНЇО<ФqТ°ПFТ²НЇО;>Т─П=Т│П"НЇО9√Т═ПQТ║НЇО7НТ≈ПVТ≤ НЇО6FТТП%ТУП3ТНЇО2ВТ≤ПaНЇО1OТґП:ТўП&НЇО/їТ▀ПcНЇО-ЪТзПMТшНЇО,WТ╘П?Т╙vНЇО*╞qТwq НЇО'┐xТ▓ПHТ⌠П.НЇО&"Т┴Т┼ПWНЇО$аТєТ╔ПaНЇО#`ТП.НЇО 5wНЇОФqТПUНЇО>ТдП\НЇО√Т╩П5Т╪П)НЇОНТПOТ НЇОFТ║П/Т╒П1НЇО·ТёП^НЇОЖТfП=y qНЇОNyqТсП5ТтНЇОіТЪ TЭс>ГdMesa for Extended Memory Altos21)Mesa 5.0 BCDs will load and execute under XMesa,2)Mesa 5.0 image files will run correctly under XMesa,3)Image files created with XMesa will run (under XMesa) on any Alto,4)Files created with Mesa 5.0 and XMesa may be debugged (under XMesa) on any Alto.Of course, these properties can be guaranteed only for programs that do not assume the existence ofextended memory.Note! Compatibility is assured only for Mesa 5.0. BCDs compiled or bound by previous releases ofthe Mesa system will NOT work properly under XMesa.The Public Interface to XMesa[Previous releases of XMesa provided their services exclusively through the XMesaDefs interface.In Mesa 5.0, some of the facilities previously available only in XMesa have been incorporated intostandard system interfaces. To aid users of XMesa 4.1 in converting to XMesa 5.0, these facilitiesare still documented here. In some cases, however, the interfaces have changed slightly.]XMesa provides most of its services through the XMesaDefs interface. However, the facilitiessupplied logically belong in other existing interfaces, notably SegmentDefs and AltoDefs. Thus,XMesaDefs actually includes several semi-independent interfaces. Unless otherwise stated,everything defined in this section comes from XMesaDefs.Configuration InformationThe facilities described in this section are defined in the MemoryOps interface, and therefore areavailable in both standard Mesa 5.0 and XMesa.The Mesa runtime system has an internal data structure that contains information about thehardware configuration of the Alto on which it is running. Clients may obtain a copy of this datastructure by writingmemoryConfig: MemoryConfig _ GetMemoryConfig[];and should normally test for the existence of extended memory by examiningmemoryConfig.useXM. The extant banks of memory are indicated by memoryConfig.banks,which is a bit mask (e.g., memoryConfig.banks=14B => banks 0 and 1 exist).BankIndex: TYPE = [0..3];MachineType: TYPE = {unknown0, AltoI, AltoII, AltoIIXM, . . . };MemoryConfig: TYPE = MACHINE DEPENDENT RECORD[reserved: [0..37B],AltoType: MachineType,useXM: BOOLEAN,mdsBank: BankIndex,secondROM: BOOLEAN,banks: [0..17B],mesaMicrocodeVersion: [0..377B],XMMicrocodeVersion: [0..377B]];НЇОfПuТНGОНюОbqНЮП0НюО`0НЮП4НюО^BНЮПBНюО\TНЮТіПPНЇОYТ┌ПKТ┐НЇОW]ТНЇОTwТ≥ПMТ НЇОRfТП3НЇОNCuНЇОJТqТ√П*Т≈П"zq НЇОILТ√Т≈ПNНЇОGєТ°П,Т²П7НЇОEЭТПZНЇОBґТ╦П+Т╧zq xqНЇОAТ└П@z qzxТ┘qНЇО?]zqТПIТНЇО=╣ТП.zqН"pО8©wТXНЇО5pqТ⌠ПГ\CCMesa for Extended Memory Altos3GetMemoryConfig: PROCEDURE RETURNS[MemoryConfig];useXM is true if and only if the following conditions hold:1)the machine is an Alto II with XM modifications (AltoType = AltoIIXM),2)the Alto has more than one memory bank installed (banks ~= 10B),3)the Alto has a second ROM (secondROM is true), and4)the second ROM contains the current version of the XMesa microcode.The microcode version fields tell only the microcode version, not the Mesa release number. (Forexample, for Mesa 5.0, mesaMicrocodeVersion is 39.) XMMicrocodeVersion will be non-zero if and only if XMesa microcode is installed in the second ROM.The procedure IsXMesa in MemoryOps provides a convenient way for a client BCD todetermine if it has been loaded into an XMesa runtime system. The return value TRUE fromIsXMesa does not guarantee that XMesa is running on a wide-bodied Alto; the client should useGetMemoryConfig to verify the existence of extended memory (see below).IsXMesa: PROCEDURE RETURNS [BOOLEAN];Unless otherwise noted, the facilities described in subsequent sections are usable only when thefollowing expression, henceforth called "the XM condition", is TRUE:IsXMesa[] AND GetMemoryConfig[].useXMExtended Memory ManagementThe facilities described in this section are defined in the XMesaDefs interface and should be usedonly when MemoryOps.IsXMesa[] is TRUE.Segments in extended memory are created with the usual primitives in SegmentDefs. However,XMesa recognizes additional "default" parameter values for those procedures that expect a VM basepage number. DefaultBase0, DefaultBase1, DefaultBase2, and DefaultBase3 requestallocation in a specific memory bank. DefaultXMBase requests allocation anywhere in theextended memory banks (banks 1-3, except for Cedar). DefaultBase (defined in SegmentDefs)requests allocation anywhere in memory (banks 0-3) if the segment is a code segment, otherwise, it isequivalent to DefaultBase0. DefaultMDSBase is equivalent (and preferred to)DefaultBase0 (except for Cedar).The following procedures logically belong in SegmentDefs. They convert between segmenthandles and long pointers, and work for segments anywhere in the 18-bit address space.XVMtoSegment: PROCEDURE [a: LONG POINTER] RETURNS [SegmentHandle];XSegmentAddress: PROCEDURE [seg: SegmentHandle] RETURNS [LONG POINTER];XVMtoDataSegment: PROCEDURE [a: LONG POINTER] RETURNS [DataSegmentHandle];ЪНЇОfПuТНGОН ОbzvТFzvНЇО^оzqТП6Н О[─НЮП1zqvqzqН ОYьНЮП2zqvqzqН ОX0НЮzq Н ОV┬НЮПCНЇОS9ТїТ╗wq wqНЇОQ▒Т╔zqТі zqНЇОOИТПCНЇОL ТЖ zqzq ТВП#НЇОJРТиП>ТйvqНЇОIJzqТ≤wqТ≥П-НЇОG╒zqТП8Н ОDSzvzТXvzvzv НЇОAqТюП>ТаП"НЇО?\ТП?vqН О< zvТFzvzН шО7wТXНЇО3хqТ┤П. The subdirectory structure parallels that used on[Iris], but only those files that supersede or supplement Mesa 5.0 are stored on .The files on are organized as follows:XMesa.image, .symbols, and .signalsBasicXMesa.image, .symbols, and .signalsXMesa.cm, BasicXMesa.cm, and MakeXMDebug.cmmiscellaneous command filesSystem>system definitions and program modules (.mesa and .bcd)miscellaneous command filesDoc>XMesa.press and .bravoXDebug>modules to be installed in the Mesa 5.0 debugger (.mesa and .bcd)The standard Mesa 5.0 version of RunMesa.run will run XMesa programs; no special version ofRunMesa is required.XMesa.cm and BasicXMesa.cm retrieve the corresponding image files, the debugger, and relatedsupporting files. MakeXMDebug.cm installs the debugger, including the modules required fordebugging the XMesa environment. (XMesa.cm and BasicXMesa.cm implicitly executeMakeXMDebug.cm as well.)Note to BasicXMesa users: The standard Mesa 5.0 version of ImageMaker.bcd may be usedwith XMesa programs. (XMesa 4.1 supplied its own.)Restrictions, Limitations, and "Features"Images and Checkpoints. MakeImage cannot preserve the contents of extended memory in theimage file it constructs. If MakeImage is invoked when the XM condition is TRUE, it will swap outall unlocked file segements in extended memory. (It will also move any locked code segments toprimary memory.) If any segments then remain in extended memory, MakeImage will refuse tobuild the image file. Analogous comments apply to CheckPoint.Bank Registers. XMesa assumes it has exclusive control of the emulator bank register. Clientprograms must not attempt to alter the bank register, but rather must use the public interfaces formoving data to and from extended memory (see XCOPY and XBitBlt, above).ЪНЇОfПuТНGОН ОbzvТFzТXvНЮО`vzvТFН О]'zvzvzТXvН ОYьzvТFzvНЮОX0zvzТXvН ОTАzvТFzvНЇОPЎuТНЇОMoqТюПVТаНЇОKгТ╛П1ТґП.НЇОJТП.Н ЮОFпН═ОE(y qyqyН═ОC─qyqyН═ОAьqy qyН═О@0qН ЮО<А Н═О;9П(yqyqН═О9▒Н ЮО6B Н═О4 y qyН═О2Рq Н═О1JП2yqyqНЇО-ШТ·П!y qТ÷НЇО,SТНЇО)yqТ▐yqПBНЇО'\ТуТжy qП:НЇО%ЄТ+П!Т,yqyqНЇО$y qТ НЇО ҐТ╦П;Т╧y qНЇОТxНЇОРuП)НЇОёwТдqТеП7НЇОШТ┼ПLvqНЇОSТ║ПGТ╒НЇО╚Т╟П0Т╠П*НЇОТП>НЇО ЄwТцqПHТдНЇОТ≥П&Т П=НЇО dТП-zqzqЪ▄Ї >Г]М/Mesa for Extended Memory Altos6Global Frame Format. XMesa exploits the full generality of the global frame format defined inControlDefs. Client programs should not assume that the code segment associated with a globalframe can be obtained by writingframe.code.handle .The constructFrameOps.CodeHandle[frame]should be used instead.Segment Object Format. The format of segment objects has changed slightly, although (forcompatibility) SegmentDefs has not been recompiled. The format assumed by XMesa appears inXMesaOps. Clients should be unaffected by this change.Segment Alignment. Segments may not cross bank boundaries.Resident Code. The amount of resident code in XMesa is 4 pages greater than in Mesa 5.0. XMesa(and BasicXMesa) also have a larger process limit (75) than the standard Mesa system, and thereforeconsume an additional page of resident data. Accordingly, XMesa may exhibit slightly poorerswapping performance on non-XM Altos than Mesa 5.0 does.Debugger Incompatibilities. The Mesa 5.0 version of XDebug cannot be used with XMesa unlessthe module XMDebug.bcd is loaded when the debugger is installed. In addition, the debugger'sCoreMap command does not work at all under XMesa. The UserProc XCoreMap should beinstalled in the debugger and used instead. The command file MakeXMDebug.cm will install thedebugger properly for use with XMesa.Swapper Algorithms. The XMesa swapper loads a segment into extended memory by first swappingit into primary memory, then copying it to extended memory and releasing the primary memoryspace. Thus, if primary memory is so full that the requested segment cannot be swapped in,InsufficientVM will be raised, even though sufficient space for the segment may exist in otherbanks. (Analogous comments apply when swapping out segments that must be written to disk.)Distribution:XMesa UsersCedar GroupMesa GroupНЇОfПuТНGОНЇОbwТ╣qТІПIНЇО`vz qТ∙Т√П:НЇО^нТН О\≥zqНЇОZdН ОX/zvzvНЇОUЗqНЇОR╚wТЯqТРП,НЇОQТ┘z qП-Т├НЇОO[zqТП/НЇОLwqП)НЇОHҐwТ┐ qП&Т└П,НЇОGТ│П;Т┌П(НЇОEmТнПUТоНЇОCеТП8НЇО@vwТїqТ╗П<НЇО>нТ╔ y qТіП(НЇО=&ТрТсП#yq НЇО;~Т÷П0Т═ y qНЇО9жТП%НЇО6┤wТ┤qП;Т┬НЇО4ъТўП[НЇО37ТлП%ТмП6НЇО1▐z qТ╟П5Т╠НЇО/ГТІП[НІО)IН хО'║ТX Н хО%Ы Н хО$Q RІ$ =ГDшMATH TIMESROMAN TIMESROMAN HELVETICALOGO TIMESROMAN HELVETICA TIMESROMAN TIMESROMAN GACHA HELVETICA ИҐ▄▌я$%)ЪЪj/,*■├нЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪXMesa.bravoLevinOctober 1, 1979 8:54 AM