From rt11@iptvax.ENET.dec.com  Thu Oct 30 13:39:47 1997
Received: by alph02.triumf.ca; id AA02054; Thu, 30 Oct 1997 13:39:47 -0800
Resent-Message-Id: <9710302139.AA02054@alph02.triumf.ca>
Resent-Date: Thu, 30 Oct 1997 13:02:52 PST
Resent-From: <shoppa@triumf.ca>
Resent-To: <shoppa@alph02.triumf.ca>
Received: from mail11.digital.com by REG.TRIUMF.CA (MX V4.0-1 VAX) with SMTP;
          Thu, 30 Oct 1997 13:02:48 PST
Received: from us7rmc.bb.dec.com (us7rmc.bb.dec.com [16.53.0.29]) by
          mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA10249; Thu,
          30 Oct 1997 15:35:32 -0500 (EST)
Received: from iptvax.enet by us7rmc.bb.dec.com (5.65/rmc-17Jan97) id AA10068;
          Thu, 30 Oct 97 15:35:28 -0500
Message-Id: <9710302035.AA10068@us7rmc.bb.dec.com>
Received: from iptvax.enet; by us7rmc.enet; Thu, 30 Oct 97 15:35:31 EST
Date: Thu, 30 Oct 97 15:35:31 EST
From: 30-Oct-1997 1335 <rt11@iptvax.ENET.dec.com>
X-Mx-Warning:   Warning -- Invalid "To" header.
To: mail11:;@us7rmc.bb.dec.com@us7rmc.bb.dec.com@unknown.domain; (@rt11)
Apparently-To: billy@mix.com, baldwin@shop-pdp.kent.edu, twelmers@netcom.com,
        timclarke@alumni.stanford.org, jimc@netcom.com,
        shal@alumni.caltech.edu, frisbie@flying-disk.com,
        sbrook@concentric.net, rcpassoc@netcom.com, shoppa@triumf.ca,
        bschor@vms.cis.pitt.edu, chip@mentec.com
Subject: (via RT11): ASCII six-monitors.doc
Status: RO

From:	IPTVAX::US3RMC::"shoppa@alph02.triumf.ca" "Tim Shoppa" 30-OCT-1997 12:35:57.28
To:	iptvax::rt11 (30-Oct-1997 1135)
CC:	
Subj:	ASCII six-monitors.doc

OK, I managed to extract most of the "flat text" from
Bob Schor's talk "Six-monitors.doc".  Notice the complete lack
of formatting and tables in the document below :-(

Tim.


Multiple Monitors in RT-11 Version 5.7
Bob Schor
Department of Otolaryngology
University of Pittsburgh
200 Lothrop Street
Pittsburgh, PA   15213
(412) 647-2116
bschor@vms.cis.pitt.edu
There are six RT-11 Version 5.7 monitors.  They can be logically 
grouped in a 2 * 3 matrix, with an almost-logical naming scheme.  The 
first division is based on the number of jobs the monitors can handle, 
and distinguishes between the "B series" and the "M series".  [This is 
the only example of an illogical name 
 for historic reasons, we call the multi-job simple monitor "FB" 
instead of the logical alternative, "SM"].  Besides looking at the 
monitor name, you can distinguish between the B and M monitors by 
examining the RMON offset $JOBS -- if it is 1, this is a B series; if 
it is greater than 1, an M series.  Similarly, within IND there is a 
parameter <JOBS> which is either 1 or a larger number, depending on the 
monitor series.
The second dimension in the matrix has three entries.  We've briefly 
mentioned the "S-series" (the Simple Monitors SB and SM, er, FB).  One 
can test for the presence of the S series by examining the KT11$ bit of 
RMON offset $CNFG1 (Configuration Word 1) 
 if it is clear, then memory management is not running, implying this 
an S-series monitor.  In IND, the symbol <MAPPED> is false.  If the 
KT11$ bit is set (or <MAPPED> is true), then we are running either an X 
or Z monitor.
Next come the "X-series", the Extended Memory monitors XB and XM.  
These monitors feature a virtual environment with the monitor and its 
services executing in Kernel space, and the user's routines kept 
separate in User space.  As in the earlier versions of RT-11, I and D 
space remain locked together, so there is no real distinction between 
program and data spaces.  To distinguish between these two, one must 
examine $CNFG3, bit CF3.SI 
 if clear, we cannot support separated I/D space, so we must be running 
the X series (I'm assuming KT11$ was also checked and found to be set). 
 There's also been a new logical symbol added to IND to distinguish 
between X and Z monitors 
 if <MODE> is false, and <MAPPED> is true, this is the X series.
The last, and newest, series of monitors are the Z monitors, ZB and ZM. 
 These provide a "completely virtual environment", featuring access to 
Kernel, Supervisor, and User modes, with full control over memory 
mapping.  This monitor will support separated I and D space programs as 
well as Supervisor Libraries, allowing you to potentially quadruple the 
memory space available to your program.  [Actually, since you can even 
use the relatively-scarce Kernel memory via a user-written handler, you 
can even squeeze out a little more than four times 64kB of 
directly-available memory space].
With all of these monitors, how do you choose rationally between them?  
In some cases, your needs force a choice.  For example, if you are 
running multiple jobs, you need the M series, instead of the B series.  
If you want to take advantage of the completely virtual environment (to 
use Supervisor Libraries, for example, or to take advantage of 
separated I/D space), you need to run a Z monitor.
What if your needs are "none of the above"?  What if you have a program 
which ran just fine under RT-11 Version 5.5?  In principle, it will run 
basically unmodified under any of the monitors.  How do you choose?  
Here are some rules of thumb.  (1) Always run ZM.  It is the biggest, 
slowest monitor of the bunch, but these days, PDP-11s come with 4Mb of 
memory, so size isn't an issue, and the speed difference (for most 
tasks) will probably not be noticable.  Anything which runs under any 
of the other monitors will run fine under ZM.  When running in this 
environment, SET RUN VBGEXE to allow VBG to be the default loader, 
which will vastly improve the performance of "VBG-aware" programs, such 
as Macr@0`@T
run them under VBG.
You can use SIPP to patch $JSX, the Job Definition Word at location 4, 
to try out various VBG options.  The bit settings of interest are:
Value
Bit name
Meaning
REQID$
Job requires separated I/D space
USEID$
Job uses separated I/D space, if possible
REQSM$
Job requires Supervisor mode
USESM$
Job uses Supervisor mode, if possible
ALL64$
Ask VBG for 64kB of memory
IOPAG$
Ask VBG to map to I/O page (PAR 7)
NOVBG$
Job cannot run under VBG
VBGEX$
Job can (and should be) run under VBG
The second rule of thumb is that if you need to tweak out some 
additional speed, for example when doing a real-time task, drop back to 
the B series.  Here you will benefit because the monitors know there is 
only a single task, there is no need to context switch between jobs, so 
don't bother unnecessarily messing with registers, checking monitor 
tables, etc.
If you want to push it to the limit, and you don't have a space 
problem, you can run SB.  Another talk discussed the Whys and 
Wherefores of SB, so I won't repeat them here.  Note that the 
reasonable upgrade path for SB (if space is a problem) is ZB, which 
trades off a little speed for a lot of memory.
The Z monitors in RT-11 Version 5.7 support running programs which 
involve separated I/D space.  What you, as a programmer, need to 
consider to take advantage of this completely virtual environment which 
allows you to have 64kB of program code directly addressing 64kB of 
user data?
The main trick in getting programs to run in a separated I/D space 
environment is to get the machine properly set up, with the programs in 
I-space and the data in D-space.  RT-11 Version 5.7 uses VBGEXE as the 
run-time loader to take .SAV images in the new executable file format 
and load them properly.  The Linker has also been made more savvy.
The mechanism used to specify what portions of your program are 
instructions (I-space) and what are data (D-space) is the .PSect 
mechanism.  If you've been diligent, have read the manuals, and have 
followed the Recommended Coding Practices, you have already been using 
.PSects properly to separate the code and data areas of your programs.  
On the other hand, if you have been relying on the past twenty years' 
experience to tell you |.PSects don't matter, you have to relearning to 
do!
What are the basic rules?  There is really only one 
 keep your code physically separated from your data, and place them in 
their proper .PSects.  Note that immediate mode "data", as in "Mov 
#BufAdr, R0" will still work, as the datum, here #BufAdr, really comes 
from I-space.
What doesn't work?  In-line arguments will fail.  This is a technique 
which Fortran has used, and may still be using.  A Fortran-style call 
is as follows:
#ArgList, R5
Call
SubRtn
.....
ArgList:.Byte
;N is number of arguments
.Byte
;Fortran only uses low byte
.Word
AdArg1
;Address of argument 1
.Word
AdArg2
;and so on
Good coding practice, required for I/D separation, is to place the 
argument list in a Data .PSect.  However, it is very easy to get lazy 
and take advantage of the unused byte at the top the list 
 if you make it 1, and interpret the first data word as an instruction, 
the sequence 
.Byte N, 1
will be executed as the branch instruction
.+2+<2*N>
which has the nifty effect of jumping you right over the argument list. 
 The bad news is that it breaks I/D separation (so don't do it!).
Normal
Default Paragraph Font
Paragraph
Code
Bob Schor"E:\PDP11\RTVer565\Six Monitors.doc
@HP LaserJet 5P/5MP PostScript
LPT1:
PSCRIPT
HP LaserJet 5P/5MP PostScript
HP LaserJet 5P/5MP PostScript
Custom page 1
Custom page 2
Custom page 3
HP LaserJet 5P/5MP PostScript
Custom page 1
Custom page 2
Custom page 3
Times New Roman
Symbol
Arial
Courier New
$Multiple Monitors in RT-11 Version 5
Bob Schor
Bob Schor
Microsoft Word Document
MSWordDoc
Word.Document.6
Multiple Monitors in RT-11 Version 5
Bob Schor
Normal.dot
Bob Schor
Microsoft Word for W
Multiple Monitors in RT-11 Version 5
indows 95
Multiple Monitors in RT-11 Version 5

% ====== Internet headers and postmarks ======
% Received: from mail13.digital.com by us3rmc.cxo.dec.com (5.65/rmc-17Jan97) id AA00868; Thu, 30 Oct 97 12:29:18 -0700
% Received: from alph02.triumf.ca (alph02.Triumf.CA [142.90.114.18]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA30616 for <rt11@iptvax.enet.DEC.com>; Thu, 30 Oct 1997 14:16:20 -0500 (EST)
% Received: by alph02.triumf.ca; id AA04844; Thu, 30 Oct 1997 11:13:50 -0800
% From: Tim Shoppa <shoppa@alph02.triumf.ca>
% Message-Id: <9710301913.AA04844@alph02.triumf.ca>
% Subject: ASCII six-monitors.doc
% To: iptvax::rt11 (30-Oct-1997 1135)
% Date: Thu, 30 Oct 1997 11:13:49 -0800 (PST)
% In-Reply-To: <9710301836.AA05159@us7rmc.bb.dec.com> from "30-Oct-1997 1135" at Oct 30, 97 01:36:22 pm
% X-Mailer: ELM [version 2.4 PL22]
% Content-Type: text


