Inter-Office MemorandumToDistributionDateApril 18, 1979FromRoy LevinLocationPalo AltoSubjectMesa for Extended Memory AltosOrganizationPARC/CSL(version 4)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,ЪН]Оg║pТiНІОc8qН]rН-єqН7BrТX НІО]ЭqН]rН-єqН7BrНІОYqН]rН-єqН7BrН]ОW│ НЭОSЛsrНЇОN"qТFП2НЇОG╗rТиПRТйНЇОFТ╒ТёПDНЇОDXТПCНЇО@5tНЇО<ФrТ°ПFТ²НЇО;>Т─П=Т│П"НЇО9√Т═ПQТ║НЇО7НТ≈ПVТ≤ НЇО6FТТП%ТУП3ТНЇО2ВТ≤ПaНЇО1OТґП:ТўП&НЇО/їТ▀ПcНЇО-ЪТзПMТшНЇО,WТ╘П?Т╙uНЇО*╞rТvr НЇО'┐wТ▓ПHТ⌠П.НЇО&"Т┴Т┼ПWНЇО$аТєТ╔ПaНЇО#`ТП.НЇО 5vНЇОФrТПUНЇО>ТдП\НЇО√Т╩П5Т╪П)НЇОНТПOТ НЇОFТ║П/Т╒П1НЇО·ТёП^НЇОЖТfП=x rНЇОNxrТсП5ТтНЇОіТ <Э_>ГYёMesa 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.Xmesa is being used by the Cedar project and certain definitions in the interface are intended exclusively for Cedar.These facilities are not described in this document; clients other than Cedar should not use them.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, D0, Dorado, AltoIV,unknown7};MemoryConfig: TYPE = MACHINE DEPENDENT RECORD[reserved: [0..37B],AltoType: MachineType,useXM: BOOLEAN,mdsBank: BankIndex,-- for Cedar onlysecondROM: BOOLEAN,НЇОfПtТНGОНюОbrНЮП0НюО`0НЮП4НюО^BНЮПBНюО\TНЮТіПPНЇОYТ┌ПKТ┐НЇОW]ТНЇОTvТ≥ПMТ НЇОRfТП3НЇОNCtНЇОJТrТ√П*Т≈П"yr НЇОILТ√Т≈ПNНЇОGєТ°П,Т²П7НЇОEЭТПZНЇОBґТ╦П+Т╧yr wrНЇОAТ└П@y rywТ┘rНЇО?]yrТПIТНЇО=╣ТП.yrНЇО:┴wТїП,Т╗ПIНЇО9ТПbН"pО4vТXНЇО0юrТ⌠ПГ]ёGMesa for Extended Memory Altos3banks: [0..17B],mesaMicrocodeVersion: [0..377B],XMMicrocodeVersion: [0..377B]];GetMemoryConfig: 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];ЪНЇОfПtТНGОНЮОbyuТFyuНЮО`vyuyuНЮО^нyuyuН О[yuyuНЇОX0yrТП6Н ОTАНЮП1yruryrН ОS9НЮП2yruryrН ОQ▒НЮyr Н ОOИНЮПCНЇОL ТїТ╗vr vrНЇОJРТ╔yrТі yrНЇОIJТПCНЇОEШТЖ yryr ТВП#НЇОDSТиП>ТйurНЇОB╚yrТ≤vrТ≥П-НЇОAyrТП8Н О=ЄyuyТXuyuyu НЇО:erТюП>ТаП"НЇО8ҐТП?urН О5nyuТFyuyН шО0xvТXНЇО-)rТ┤ПDoc>Microcode.press for details.How to Obtain and Use XMesaThe files for XMesa reside on [Ivy]. 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)source and object code for microcode (in a .dm file)miscellaneous command filesDoc>XMesa.press and .bravoMicrocode.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.The microcode that must be installed in the second control ROM is stored inSystem>XMesaROM.mb. This file is in suitable form for use by the PROM blaster.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 executeНЇОfПtТНGОН Оby uТFНЇО^оrТіПLТїНЇО]'yrТ"Т#yry rНЇО[ТП6Н ОX0yuТFyТXuНЮОV┬yuТFН ОS9yuyuyТXuН ОOЙyuТFyuНЮОNByuyТXuН ОJСyuТFyuНЇОGгwТ╘П!zwzwzwП"Т╙НЇОFfТ▓zwП9Т⌠zwП%НЇОDБТП,НЇО@©tНЇО=prТюПVТаНЇО;хТ╛П1ТґП.НЇО: ТП.Н ЮО6яН═О5)x rxrxН═О3│rxrxН═О1ыrx rxН═О01rН ЮО,Б Н═О+:П(xrxrН═О)▓П+xrН═О'ЙН ЮО$⌡ Н═О"Сx rxН═О!KrxН ЮОЭr Н═ОTП2xrxrНЇОТ·П!x rТ÷НЇО]ТНЇОТ∙Т√П1НЇОfxrwТП<НЇОxrТ▐xrПBНЇО oТуТжx rП:НЇОгТ+П!Т,xrxrРЇ─>Г\┼.Mesa for Extended Memory Altos6MakeXMDebug.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).Global 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.Microcode in the RAM. The microcode to support XMesa occupies more than 1K of controlmemory space. Most of it resides in the second 1K of control ROM (ROM1), with the excessoverflowing into the RAM. The remaining RAM space is available to users who wish to write theirown microcode, but certain conventions must be observed. Those who need to execute specialmicrocode from Mesa programs should consult [Ivy]Doc>Microcode.press (and .bravo).Note to XMesa 4.1 clients who provide special microcode: the amount of overflow into the RAM has increased inXMesa 5.0. If you are short of microcode space, the document previously referenced describes ways to increase theamount of available RAM.НЇОfПtТНGОНЇОbx r НЇО^оТ╦П;Т╧x rНЇО]'ТwНЇОYtП)НЇОU╣vТдrТеП7НЇОT Т┼ПLurНЇОReТ║ПGТ╒НЇОPҐТ╟П0Т╠П*НЇОOТП>НЇОKфvТцrПHТдНЇОJТ≥П&Т П=НЇОHvТП-yryrНЇОE'vТ╣rТІПIНЇОCy rТ∙Т√П:НЇОAвТН О?╒yrНЇО=mН О;8yuyuНЇО9rНЇО5ЄvТЯrТРП,НЇО4Т┘y rП-Т├НЇО2dyrТП/НЇО/vrП)НЇО+фvТ┐ rП&Т└П,НЇО*Т│П;Т┌П(НЇО(vТнПUТоНЇО&нТП8НЇО#vТїrТ╗П<НЇО!вТ╔ x rТіП(НЇО /ТрТсП#xr НЇО┤Т÷П0Т═ x rНЇОъТП%НЇО░vТнrПAНЇОХТ╧Т╨ПLНЇО@Т┘П(Т├П8НЇО≤Тю ТаПMНЇОПТъПPТЮwНЇОkТ╛П-ТґПAНЇО Т╛ПbТґНЇО├ТЪ≤Ї?>ГYк;Mesa for Extended Memory Altos7Swapper 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ПtТНGОНЇОbvТ┤rП;Т┬НЇО`vТўП[НЇО^нТлП%ТмП6НЇО]&y rТ╟П5Т╠НЇО[~ТІП[НІОTЮН хОS8ТX Н хОQ░ Н хОOХ ІO║=ГiH TIMESROMAN HELVETICA TIMESROMAN LOGO TIMESROMAN HELVETICA TIMESROMAN TIMESROMANGACHA HELVETICA TIMESROMANП╧╒┐р#е+╦.ЪЪj/1/⌠DРуЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪXMesa.bravoLevinApril 18, 1979 12:49 PM