Service Manuals, User Guides, Schematic Diagrams or docs for : xerox mesa Alto_Mesa_1974

<< Back | Home

Most service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.




Image preview - the first page of the document
Alto_Mesa_1974


>> Download Alto_Mesa_1974 documenatation <<

Text preview - extract from the document
           Inter-Office (VJem.ornndum


To     CSL, SSL                                   Date
                                                                  June 12,1274.

From      Jim Mitchell                            Location        PARC-CSL

Subject     What Mesa needs in an Alto            Organizlltion
            Virtual Memory Scheme




     Since there has been much discussion of Virtual Memory (VM) schemes
in the context of Alto "Gold Coins", it seemed appropriate that the
desires of the Mesa group be specified. This memo is a reasonably high
level description of the characteristics which would be helpful to Mesa
in a VM scheme.
Mesa Object Files
     A Mesa Object Module (file) is composed of two main parts, each of
which is a contiguous group of pages in the file:

                                    header info
                                                             n pages
                                    object code
                                      literals

                                         symbol                   pages
                                         tables


Generally, s is larger than n, and sometimes             s is twice as large as n.
      The action of "loading" a Mesa module requires only that the code
 pages be mapped into memory. The code is never altered in any way - all
 external connections (generally procedures and ports) are in the data
 associated with a program. A Mesa routine (procedure or coroutine) is
 uniquely identified by a frame containing its state and local variables,
 and many routines may share the code in an object module. The information
 which allows Mesa to associate a symbol table and code with a routine is
 kept in a frame called a creator frame. The act of "declaring" an object
'file to Mesa causes a creator frame for that file to be made. Instances
 of that module can then be created simply by transferring control to its
creator; the result is a new routine. The cost of creating new instances
is roughly comparable with the cost of a procedure call.
     The header information in the code block of an object file contains
sufficient information to enable the Mesa loader to manufacture a creator
for it.

Abstractions for Managing (Overlaying) Code Blocks
     A contiguous set of file pages is called a ~ group in Mesa, and
is identified by three values:
       filehandle: some handle on a file by which the pages of the file
                    can be named (for example, a JFN in Tenex);
       pagebase: the page in the file which corresponds to page zero in
                  the page group;
       size: the numb~r of pages in the group.'
     A page group is accessed by a PG-handle (actually a protected [sealed]
pointer) and page groups may be created, destroyed, and swapped into
memory or out. More than one page group may, in principle, be associated
with the same pages in a file. On Tenex this is accomplished by PMAPping
the appropiate file pages into the Tenex VM. One special kind of page
group, called a Window group, is provided: the pagebase and size attri-
butes of such a group are alterable after it is initially set up, and it
can thus "window" pages of the file to which it is attached.
     The code and symbol table parts of a Mesa module are each modelled as
a fixed page group by the Mesa loader, overlaying and debugging software.
The main implication of this is that Mesa code is "svJapped" (overlayed) in
units corresponding to the code in a single module. Symbol tables, being
separately swappable, only consume VM space when needed by debugging or
dynamic (LISP-like) binding mechanisms.
     The following diagram portrays the relationships between the Tenex
page-grouped VM as seen by Mesa, File memory, and Maxc disk storage (see
next page, please):




                               -2-
                                                  D:~k
                                                  sCI.) I'v..~-L




    . One obvious conclusion from this diagram is that the logical grouping
of fi1e pages which Mesa considers useful is not at all maintained at the
level of disk storage. A second observation is that the Tenex-provided VM
is being treated as a real memory into which a much larger VM, composed
of page groups, is mapped. For obvi ous effi ci ency reasons_ on Tenex, only
Mesa code and symbol tables are considered swappable because pointers to
them can be controlled by software (for not-in-memory traps, etc.).
Mesa/Alto
     We would like to propose a VM scheme for Altos which supports a struc-
ture such as the following:
      A



◦ Jabse Service Manual Search 2022 ◦ Jabse PravopisonTap.bg ◦ Other service manual resources online : FixyaeServiceinfo